ETSITS124 292V8.4.0 



(2010-01) 



Technical Specification 



Universal Mobile Telecommunications System (UMTS); 

LTE; 
IP Multimedia Core Network subsystem Centralized Services; 

Stage 3 
(3GPP TS 24.292 version 8.4.0 Release 8) 



33i^ 





3GPP TS 24.292 version 8.4.0 Release 8 1 ETSI TS 1 24 292 V8.4.0 (201 0-01 ) 



Reference 



RTS/TSGC-01 24292V840 
Keywords 



LTE, UMTS 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2010. 
All rights reserved. 

DECT™, PLUGTESTS™, UMTS™, TIPHON™, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered 

for the benefit of its Members. 
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 

LTE™ is a Trade Mark of ETSI currently being registered 

for the benefit of its Members and of the 3GPP Organizational Partners. 

GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association. 



ETSI 



3GPP TS 24.292 version 8.4.0 Release 8 2 ETSI TS 1 24 292 V8.4.0 (201 0-01 ) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http://webapp.etsi.org/kev/quervform.asp . 



ETSI 



3GPP TS 24.292 version 8.4.0 Release 8 3 ETSI TS 1 24 292 V8.4.0 (201 0-01 ) 



Contents 



Intellectual Property Rights 2 

Foreword 2 

Foreword 7 

1 Scope 8 

2 References 8 

3 Definitions and abbreviations 10 

3.1 Definitions 10 

3.2 Abbreviations 11 

4 Overview of IP Multimedia (IM) Core Network (CN) subsystem centralized services (ICS) 12 

4.1 General 12 

4.2 Underlying network capabilities 12 

4.3 URI and address assignments 13 

5 Functional entities 13 

5.1 Introduction 13 

5.2 User Equipment (UE) 13 

5.3 MSC Server enhanced for ICS 14 

5.4 Application Server (AS) 14 

6 Roles for registration in the IM CN subsystem 14 

6.1 Introduction 14 

6.2 ICSUE 14 

6.3 MSC Server enhanced for ICS 15 

6.3.1 General 15 

6.3.2 Initial registration 15 

6.3.3 Sending the REGISTER request 17 

6.3.4 Subscription to the registration-state event package 17 

6.3.5 Reregistration 18 

6.3.6 Deregistration 19 

6.3.6.1 S-CSCF initiated deregistration 19 

6.3.6.2 MSC Server enhanced for ICS initiated deregistration 19 

6.4 sec AS 20 

7 Roles for call origination 20 

7.1 Introduction 20 

7.2 ICSUE 20 

7.2.1 General 20 

7.2.2 ICSUE using Gm 20 

7.2.3 ICSUE using CS 21 

7.3 MSC Server enhanced for ICS 21 

7.4 sec AS 21 

7.4.1 General 21 

7.4.2 sec AS for service control over Gm 21 

7.4.2.1 CS bearer is requested by the ICS UE 21 

7.4.2.2 Non CS bearer is requested by the ICS UE 23 

7.4.3 sec AS for service control over CS 23 

8 Roles for call modifcation initiated from the ICS UE 23 

8.1 Introduction 23 

8.2 ICSUE 24 

8.2.1 General 24 

8.2.2 ICS UE is using Gm 24 

8.2.2.1 General 24 

8.2.2.2 ICS UE adds a CS bearer 24 

8.2.2.3 ICS UE adds voice media in PS domain 24 



£75/ 



3GPP TS 24.292 version 8.4.0 Release 8 4 ETSI TS 1 24 292 V8.4.0 (201 0-01 ) 

8.2.2.4 ICS UE adds a non-voice media in PS domain 24 

8.2.2.5 ICS UE removes a CS bearer 24 

8.2.2.6 ICS UE removes PS media 24 

8.3 MSC server enhanced for ICS 24 

8.4 sec AS 25 

8.4.1 General 25 

8.4.2 sec AS actions when UE adds a CS bearer 25 

8.4.3 sec AS adds media in the PS domain 26 

9 Roles for call modifcation initiated towards an ICS UE 26 

9.1 Introduction 26 

9.2 ICSUE 26 

9.2.1 General 26 

9.2.2 ICSUE using Gm 26 

9.2.2.1 General 26 

9.2.2.2 ICS UE is offered a CS bearer 26 

9.2.2.3 ICS UE is offered another media 26 

9.2.2.4 ICS UE is offered a voice media both in CS and PS domain 26 

9.2.2.5 sec AS removes a CS bearer 26 

9.2.2.6 see AS removes PS media 26 

9.3 MSC server enhanced for ICS 27 

9.4 sec AS 27 

9.4.1 Terminating Access domain selection 27 

9.4.2 see AS adds a CS bearer 27 

9.4.3 see AS adds PS media 28 

9.4.4 see AS removes a CS bearer 28 

10 Roles for call termination 28 

10.1 Introduction 28 

10.2 ICSUE 28 

10.2.1 General 28 

10.2.2 ICSUE using Gm 28 

10.2.2.1 General 28 

10.2.2.2 Call control over Gm and voice over IP bearer 29 

10.2.2.3 Call control over Gm and voice over CS bearer 29 

10.2.2.4 Call control over Gm and T-ADS executed by the UE 29 

10.2.3 ICSUE using CS 32 

10.2.4 CS fallback 32 

10.3 MSC Server enhanced for ICS 32 

10.4 sec AS 32 

10.4.1 General 32 

10.4.2 Terminating Access Domain Selection 32 

10.4.3 sec AS for call termination in IM CN 33 

10.4.4 see AS for call control over Gm and voice over CS 34 

10.4.5 see AS for call termination ICS Enhanced MSC Server 35 

10.4.6 see AS allowing UE to execute T-ADS 35 

10.4.7 see AS for call termination over CS to non-ICS UE 36 

11 Roles for session release 36 

11.1 Introduction 36 

11.2 ICSUE 37 

11.2.1 General 37 

11.2.2 ICSUE using Gm 37 

11.2.3 ICSUE using CS 37 

11.3 MSC Server enhanced for ICS 37 

11.4 see AS 37 

11.4.1 General 37 

11.4.2 see AS for service control over Gm 37 

11.4.3 see AS procedure upon loss of Gm service control 38 

12 Supplementary service invocation for ICS 38 

12.1 Supplementary service invocation for an ICS UE with IMS sessions using CS bearer 38 

12.1.1 Overview 38 



£75/ 



3GPP TS 24.292 version 8.4.0 Release 8 5 ETSI TS 1 24 292 V8.4.0 (201 0-01 ) 

12.1.2 Use of Gm reference point 38 

12.1.2.1 Line ID Services (OIP, OIR, TIP, TIR) 38 

12.1.2.2 Communication Diversion Services 38 

12.1.2.3 Communication Barring 38 

12.1.2.4 Communication Hold/Resume 38 

12.1.2.5 Explicit Communication Transfer 39 

12.1.2.6 Conferencing 39 

12.1.2.7 Communication Waiting 39 

12.1.4 When use of Gm reference point is not possible due to VPLMN limitations 39 

12.1.4.1 When attached to an MSC Server enhanced for ICS 39 

12.1.4.2 When attached to an MSC Server not enhanced for ICS 39 

12.2 Supplementary service invocation using the MSC Server enhanced for ICS 40 

12.2.1 Line ID Services (OIP, OIR, TIP, TIR) 40 

12.2.2 Communication Diversion (CDIV) Services 40 

12.2.2.1 General 40 

12.2.2.2 Communication Forwarding Unconditional (CFU) 40 

12.2.2.3 Communication Forwarding Busy (CFB) 40 

12.2.2.4 Communication Forwarding No Reply (CFNR) 40 

12.2.2.5 Communication Forwarding on Not Logged-in (CFNL) 40 

12.2.2.6 Communication Deflection (CD) 40 

12.2.2.7 Communication Forwarding on Subscriber Not Reachable (CFNRc) 40 

12.2.2.8 Communication Diversion Notification (CDIVN) 41 

12.2.2.9 Diversion notifications to originating users 41 

12.2.3 Communication Barring (CB) 41 

12.2.4 Communication Hold/Resume 41 

12.2.5 Explicit Communication Transfer (ECT) 41 

12.2.6 Conferencing 41 

12.2.7 Communication Waiting (CW) 42 

12.3 Supplementary service invocation for non ICS UE when attached to an MSC Server not enhanced for 

ICS 42 

12.3.1 Line ID Services (OIP, OIR, TIP, TIR) 42 

12.3.2 Communication Diversion services 42 

12.3.2.1 Communication Diversion services; CFU, CFNL 42 

12.3.2.2 Communication Diversion services; CFNR, CFB 42 

12.3.2.3 Communication Diversion services; Communication Deflection 42 

12.3.3 Communication Barring 42 

12.3.4 Communication Hold/Resume 42 

12.3.5 Explicit Communication Transfer 42 

12.3.6 Conferencing 42 

12.3.7 User configuration of supplementary services 43 

13 Supplementary service configuration for ICS 43 

13.1 General 43 

13.2 ICSUE 43 

13.3 MSC server enhanced for ICS 43 

Annex A (informative): Example signalling flows 44 

A.l Scope of signalling flows 44 

A.2 Introduction 44 

A.2.1 General 44 

A.2. 2 Key required to interpret signalling flows 44 

A. 3 Signalling flows for registration 45 

A.3.1 Signalling flows for CS UE IMS registration when using an MSC Server enhanced for ICS 45 

A.4 Signalling flows for call origination 52 

A.4.1 Signalling flows for ICS UE origination with CS media using Gm reference point when using an MSC 

Server enhanced for ICS 52 

A.4. 2 Signalling flows for ICS UE origination with CS media using Gm reference point when using an MSC 

Server not enhanced for ICS 61 

A.4. 3 Signalling flows for CS UE origination when using an MSC Server enhanced for ICS — multiple 

codecs used 65 



£75/ 



3GPP TS 24.292 version 8.4.0 Release 8 6 ETSI TS 1 24 292 V8.4.0 (201 0-01 ) 

A.4.4 Signalling flows for CS UE origination when using an MSC Server enhanced for ICS - one codec used 73 

A.4.5 Signalling flows for CS UE origination when using an MSC Server not enhanced for ICS 78 

A.5 Signalling flows for call termination 85 

A.5.1 Signalling flows for termination to a CS UE registered in IMS using an MSC Server enhanced for ICS - 

multiple codecs used 85 

A. 5. 2 Signalling flows for termination to a CS UE not registered in IMS 94 

A. 5. 3 Signalling flows for termination to an ICS UE with CS media using Gm reference point when using an 

MSC server enhanced for ICS 98 

A. 5. 4 Signalling flows for termination to an ICS UE with CS media using Gm reference point when using an 

MSC Server not enhanced for ICS 107 

A. 5. 5 Signalling flows for termination to an ICS UE with CS media using Gm reference point when using an 

MSC Server enhanced for ICS and UE assisted T-ADS 1 1 1 

A. 6 Signalling flows for supplementary service invocation for ICS 120 

A. 6.1 Communication Hold/Resume with Announcement 120 

A.6.2 Explicit Communication Transfer using Gm reference point, ICS UE as transfer recipient 126 

A.6.3 Communication Waiting 133 

A. 6. 3.1 Communication Waiting when using Gm 133 

A. 6. 3.2 Communication Waiting via the MSC Server enhanced for ICS 137 

Annex B (normative): Media feature tags defined within the current document 142 

B.l General 142 

B.2 Definition of media feature tag g.3gpp.ics 142 

B.3 Definition of media feature tag g.Sgpp.accesstype 142 

Annex C (informative): Change history 144 

History 147 



£75/ 



3GPP TS 24.292 version 8.4.0 Release 8 7 ETSI TS 1 24 292 V8.4.0 (201 0-01 ) 



Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



IP Multimedia (IM) Core Network (CN) subsystem centralized services (ICS) allow for the delivery of consistent IMS 
services to the user regardless of the attached access type (e.g. CS domain access or IP-CAN). 

The present document provides the protocol details for the realization of ICS based on the Session Initiation protocol 
(SIP), the Session Description Protocol (SDP) and the protocols of the 3GPP Circuit-Switched (CS) domain (e.g. CAP, 
MAP, ISUP, BICC and the NAS call control protocol for the CS access). 

This document makes no ICS specific enhancements to SIP or SDP beyond those specified in 3GPP TS 24.229 [11]. 

The present document is applicable to User Equipment (UEs), MSC Servers and Application Servers (AS) providing 
ICS capabilities. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 
3GPPTR 21.905 [1]. 

CS call: A connection established via the circuit switched domain in accordance with the related procedures e.g. such 
as described in 3GPP TS 24.008 [8], 3GPP2 C.SOOOl-D [37] and of which the estabHshed bearer is only used within a 
CS connection but not used as a media stream for a related IM CN subsystem session. 

CS media: A media stream estabhshed through CS signalling (e.g. 3GPP TS 24.008 [8], 3GPP2 C.SOOOl-D [37]) and 
transported through the PSTN with a session description defined by draft-ietf-mmusic-sdp-cs [36]. 

NAS combined attach or TA update: A NAS attach procedure where the EPS attach type is set to combined 
EPS/IMSI attach or a NAS tracking area update procedure where the EPS update type is set to combined TA/LA 
updating with IMSI attach. See also 3GPP TS 24.301 [1 1 A]. 

Successful NAS combined attach or TA update: The successful outcome of a NAS combined attach procedure where 
for the NAS attach procedure the EPS attach result is combined EPS/IMSI attach or where for the NAS tracking area 
update procedure the EPS update result is combined TA/LA updated or combined TA/LA updated and ISR activated. 
See also 3GPP TS 24.301 [1 lA]. 

PSI DN: A tel URI (see RFC 3966 [42]) or SIP URI with the "user" SIP URI parameter set to "phone", in accordance 
with 3GPP TS 23.003 [4], subclause 13.5. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.292 [6] apply: 
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ICSUE 

Correlation MSISDN 
MSC Server enhanced for ICS 
sec AS 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.629 [19] apply: 

transferee 
transferor 
transfer target 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.228 [5] apply: 

Public Service Identity (PSI) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.003 [3] apply: 

CS Domain Routeing Number (CSRN) 
IP Multimedia Routeing Number (IMRN) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.301 [11 A] apply: 

EPS attach result 

EPS attach type 

EPS update result 

EPS update type 

IMS Voice over PS Session (IMSVoPS) indicator 

TA 



3.2 



Abbreviations 



For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [1]. 

ADS Access Domain Selection 

AS Application Server 

BICC Bearer Independent Call Control 

CAMEL Customised Applications for Mobile network Enhanced Logic 

CB Communication Barring 

CD Communication Deflection 

CDIV Communication Diversion 

CDIVN Communication Diversion Notification 

CFNL Communication Forwarding on Not Logged-in 

CFNR Communication Forwarding No Reply 

CFNRc Communication Forwarding on subscriber Not Reachable 

CFU Communication Forwarding Unconditional 

CN Core Network 

CSFB CS Fall Back 

CSRN CS domain Routing Number 

CW Communication Waiting 

DN Directory Number 

ECT Explicit Communication Transfer 

ICS IMS CentraUzed Services 

IMSVoPS IMS Voice over PS Session 

lUA ICS User Agent 

HLR Home Location Register 

HSS Home Subscriber Server 

IM IP Multimedia 

IMRN IP Multimedia Routeing Number 

MSC Mobile Switching Center 

NAS Non Access Stratum 

OIP Originating Identification Presentation 
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OIR Originating Identification Restriction 

sec AS Service Centralization and Continuity Application Server 

T-ADS Terminating ADS 

TA Tracking Area 

TIP Terminating Identification Presentation 

TIR Terminating Identification Restriction 

UA User Agent 

UE User Equipment 

URI Universal Resource Identifier 

4 Overview of IP Multimedia (IIVI) Core Network (CN) 

subsystem centralized services (ICS) 

4.1 General 

ICS allows for the delivery of consistent IMS services to the user regardless of the attached access type (e.g. CS domain 
access or IP -CAN). ICS provides communication services such that all services, and service control, are based on IM 
CN subsystem mechanisms and enablers. This includes enabling IM CN subsystem services when using CS access for 
the media bearer. 

When using a CS access network, or when using a PS access networks that does not support the full duplex speech 
component of an IM CN subsystem service, the CS core network is utilized to establish a circuit switch access 
according to e.g. 3GPP TS 24.008 [7] or 3GPP2 C.SOOOl-D [37] for use as media for IM CN subsystem sessions. 

If the PS access network does support the full duplex speech component of an IMS service then existing IM CN 
subsystem session procedures are used as specified in 3GPP TS 24.229 [11]. 

ICS provides mechanisms to support the use of CS media bearer for IM CN subsystem sessions. With ICS, IM CN 
subsystem sessions using CS media are treated as standard IM CN subsystem sessions for the purpose of service 
control. 

Sessions originated by ICS subscribers in both the IM CN subsystem and in the CS domain are subject to anchoring in 
the IM CN subsystem. Similarly, voice calls terminated to ICS subscribers are anchored in the IM CN subsystem. When 
anchoring occurs, such sessions have a path to the SCC AS from either the CS access domain or the IM CN subsystem 
so that the SCC AS can be used to provide service centralization. 

In order for the above to occur, the following procedures are supplied within this specification: 

procedures for call origination are specified in Clause 7; 

procedures for call modification initiated from the ICS UE are specified in Clause 8; 

procedures for call modification initiated towards an ICS UE are specified in Clause 9; 

procedures for call termination are specified in Clause 10; 

procedures for session release are specified in Clause 1 1 ; and 

procedures for supplementary service invocation for ICS are specified in Clause 12. 

4.2 Underlying network capabilities 

ICS assumes the use of a number of underlying network capabilities: 

1) provision by the home network operator of an ICS specific AS on the IM CN subsystem, as specified in 

3GPPTS 24.229 [11]; 

2) signalling within the CS domain (both within the home network and between the home network and any visited 
network) supported using either ISUP (as defined in ITU-T Recommendations Q.761 to Q.764 [28]) or BICC (as 
defined in ITU-T Recommendations Q.1902.1 to Q.1902.6 [29]); 
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3) provision of CAMEL Phase 2 or later (as specified in 3GPP TS 29.078 [21]) at the MSC Server; 

4) if the MSC Server is not enhanced for ICS, interworking between the CS domain and the IM CN subsystem is 
provided by an MGCF in accordance with 3GPP TS 29.163 [22]; and 

5) capability of the IP-CAN to support full duplex speech component, for example as used in IMS multimedia 
telephony. 

4.3 URI and address assignments 

In order to support ICS to a subscriber the following URI and address assignments are assumed: 

a) the ICS UE will be configured to be reachable in both the IM CN subsystem and the CS domain by one to many 
public telecommunication numbers which should be correlated between the CS domain and IM CN subsystem. 
The subscriber's IM CN subsystem profile will need to be provisioned with a tel URI, either as the default public 
user identity or associated with it, equivalent to a DN (e.g. MSISDN) in the subscriber's CS profile associated 
with speech/audio (e.g. TSll). 

c) a PSI DN is assigned that can reach an ICS application that can support the ICS capabilities for that ICS UE. The 
PSI DNs can be dynamically allocated at the time that the call is rerouted to the IM CN subsystem for ICS 
purposes. The PSI DN is used specifically in the case of Gm service control for the purpose of CS bearer setup 
and does not apply to other procedures. The IM CN subsystem is configured to treat the PSI DN as a PSI; 

d) a non ICS UEs which are not registered in the IM CN subsystem might still be attached to the CS network at an 
MSC. In this scenario, a CSRN is assigned for routing the call to the CS domain; 

e) an MSC Server enhanced for ICS shall use a private user identity and public user identity specifically reserved 
for IM CN subsystem registrations from an MSC Server. This is to avoid conflicts in IM CN subsystem 
registration by a UE and an MSC Server registering on behalf of the same subscriber. The identities reserved for 
ICS identities are defined in 3GPP TS 23.003 [4]; and an MSC Server shall use only those public user identities 
representing E. 164 numbers from the subscriber's IM CN subsystem profile to originate and terminate calls; 

f) an MSC Server enhanced for ICS is provisioned with a string that identifies the visited network at the home 
network. The string needs to be different than the value provisioned to a P-CSCF, as specified in 

3GPP TS 24.229 [11], in order to distinguish between a P-CSCF and an MSC Server enhanced for ICS; and 

g) an IMRN is assigned that can reach an ICS application that can support the ICS capabilities for that UE. IMRNs 
can be dynamically allocated. The IM CN subsystem is configured to treat the IMRN as a PSI. 

h) an MSC Server enhanced for ICS shall provide a home network domain name from the subscriber's IMSI as 
defined in 3GPP TS 23.003 [4]. 



5 Functional entities 

5.1 Introduction 

This clause associates the functional entities described for the IM CN subsystem and for the CS domain, with the ICS 
roles described in the stage 2 architecture document (see 3GPP TS 23.292 [6]). 



5.2 User Equipment (UE) 



A UE that is compliant with this specification, shall implement the role of ICS UE capabilities defined in 
subclauses 6.2, 7.2, 8.2, 9.2, 10.2 and 11.2. 
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5.3 MSC Server enhanced for ICS 

The MSC Server enhanced for ICS shall provide the UA role as defined in Annex A of 3GPP TS 24.229 [11], with the 
exceptions and additional capabilities as described in subclauses 6.3, 7.3, 8.3, 9.3, 10.3 and 11.3. 

5.4 Application Server (AS) 

The ICS AS provides the following roles: 

a) ICS User Agent (lUA) as defined in 3GPP TS 23.292 [6] subclause 5.3.1; 

b) Terminating Access Domain Selection (T-ADS) as defined in 3GPP TS 23.292 [6] subclause 5.3.1; 

An AS implementing the ICS application shall implement one or more of the roles lUA or T-ADS. Both roles can be 
co-located. 



6 Roles for registration in the IM CN subsystem 

6.1 Introduction 

This clause specifies procedures that are related to registration in the IM CN subsystem that are required for support of 
ICS. Both when the ICS UE generates the registration and when the MSC Server enhanced for ICS generates the 
registration is covered. 

Subclause A.3 gives examples of signalling flows for registration. 

6.2 ICS UE 

Prior to performing IMS registration the ICS UE shall check that the ICS MO ICS_Capabilities_Enabled leaf node (see 
3GPP TS 24.286 [43]) is set to enabled for this ICS UE; otherwise ICS is disabled for this ICS UE and the ICS UE shall 
perform as in 3GPP TS 24.229 [1 1] and in 3GPP TS 24.008 [7]. 

If the ICS UE has an IMEI, prior to performing registration, the ICS UE shall generate an instance id based on its IMEI 
as defined in 3GPP TS 23.003 [4]. 

If ICS is enabled then the ICS UE registers to IM CN subsystem as specified in 3GPP TS 24.229 [11] and includes its 
capabilities in the Contact header field including the media feature-tag applicable for ICS. The ICS UE shall include in 
the Contact header field: 

a) a g.3gpp.ics media feature tag set to principal as specified in annex B.2; and 

b) a g.3gpp.accesstype media feature tag set to one of the following text strings based on the access network 
technology being used by the UE to register, as follows: 

- "wlan": the UE is using WLAN access technology. 

- "cellular": the UE is using cellular access technology. 

- "docsis": the UE is using DOCSIS access technology. 

- "dsl": the UE is using DSL access technology. 

- "ethernet": the UE is using Ethernet access technology. 

Additionally to ensure that the text string is unique for that registration flow the UE shall append a unique numerical 
single digit value for each registration flow to the text string value above (e.g "wlanl"); and 

c) a sip. instance media feature tag containing the instance ID; 
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6.3 MSC Server enhanced for ICS 

6.3.1 General 

Prior to performing registration on behalf of a UE, the MSC Server enhanced for ICS shall generate 

a private user identity; 

an instance id; 

a temporary public user identity; and 

a home network domain name to address the REGISTER request to; 

in accordance with the procedures as described in 3GPP TS 23.003 [4]. 

NOTE: The condition when the MSC Server enhanced for ICS initiates registration on behalf of a UE is described 
in 3GPPTS 29.292 [24]. 

Prior to performing registration on behalf of a UE, the MSC Server enhanced for ICS shall obtain the IMEI of the UE 
using procedures as defined in 3GPP TS 24.008 [7]. The IMEI shall be used to create the instance id as defined in 
3GPPTS 23.003 [4]. 

6.3.2 Initial registration 

On sending a REGISTER request, the MSC Server enhanced for ICS shall: 

1) set the Request-URI to the SIP URI of the domain name of the home network used to address the REGISTER 
request; 

2) set the From header field to the SIP URI that contains the temporary public user identity to be registered; 

3) set the To header field to the SIP URI that contains the temporary public user identity to be registered; 

4) populate an Authorization header field, with: 

the username directive, set to the value of the private user identity; 

the realm directive, set to the domain name of the home network; 

the integrity-protected directive, set to "auth-done"; 

the uri directive, set to the SIP URI of the domain name of the home network; 

the nonce directive, set to an empty value; and 

the response directive, set to an empty value; 

5) set the Contact header field to include the SIP URI containing the IP address or FQDN of the MSC Server 
enhanced for ICS in the hostport parameter. The MSC Server enhanced for ICS shall include a +sip. instance 
parameter containing the instance ID. The MSC Server enhanced for ICS shall include a 

a) g.3gpp.icsi-ref media feature tag as specified in 3GPP TS 24.229 [11] the value for the IMS Multimedia 
Telephony Communication Service as specified in 3GPP TS 24.173 [9]; and 

b) g.3gpp.ics media feature tag set to server as specified in subclause annex B.2. 

6) set the Via header field to include the IP address or FQDN of the MSC Server enhanced for ICS in the sent -by 
field; 

7) set the Expires header field, or the expires parameter within the Contact header field, to the value of 600 000 
seconds for the duration of the registration; 
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NOTE: The registrar (S-CSCF) might decrease the duration of the registration in accordance with network pohcy. 
Registration attempts with a registration period of less than a predefined minimum value defined in the 
registrar will be rejected with a 423 (Interval Too Brief) response. 

8) populate the Supported header field with the option tag "gruu"; 

9) populate the Require header field with the option tag "path"; 

10) populate the Path header field with: 

- a SIP URI identifying the MSC Server enhanced for ICS; 

an indication that requests routed in this direction of the path (i.e. from the S-CSCF towards the MSC Server 
enhanced for ICS) are expected to be treated as for the terminating case; 

1 1) populate the P-Charging- Vector header field with the icid parameter populated as specified in 

3GPP TS 32.260 [18] and a type 1 orig-ioi parameter. The MSC Server enhanced for ICS shall set the type 1 
orig-ioi parameter to a value that identifies the sending network of the request. The MSC Server enhanced for 
ICS shall not include the type 1 term-ioi parameter; 

12) populate the P-Visited-Network-ID header field with the value of a pre-provisioned string that identifies the 
visited network at the home network as specified in subclause 4.3; and 

13)forward the request as specified in subclause 6.3.3. If the MSC Server enhanced for ICS fails to forward the 
REGISTER request, the MSC Server enhanced for ICS shall abort the initial IMS registration attempt. 

On receiving a 200 (OK) response to the REGISTER request, the MSC Server enhanced for ICS shall: 

1) store the expiration time of the registration for the public user identities found in the To header field value; 

2) store the list of Service-Route headers preserving the order, in order to build a proper preloaded Route header 
value for new dialogs and standalone transactions. The MSC Server enhanced for ICS shall store this list during 
the entire registration period of the respective public user identity; 

3) associate the Service-Route header list with the registered public user identity; 

4) store as the default public user identity the first URI in the list of URIs present in the P-Associated-URI header 
field; 

5) treat the identity under registration as a barred public user identity, if it is not included in the P-Associated-URI 
header field; 

6) find the Contact header field within the response that matches the one included in the REGISTER request. If this 
contains a "pub-gruu" parameter or a "temp-gruu" parameter or both, then store the value of those parameters as 
the GRUUs for the UE in association with the public user identity that was registered; 

7) store the values received in the P-Charging-Function- Addresses header field; and 

8) if a term-IOI parameter is received in the P-Charging- Vector header field, store the value of the received term- 
lOI parameter. 

On receiving a 423 (Interval Too Brief) response to the REGISTER request, the MSC Server enhanced for ICS shall: 

- send another REGISTER request populating the Expires header field or the expires parameter within the Contact 
header field with an expiration timer of at least the value received in the Min-Expires header field of the 423 
(Interval Too Brief) response. 

When the timer F expires at the MSC Server enhanced for ICS, the MSC Server enhanced for ICS may: 

1) select a different exit or entry point as described in this subclause; and 

2) perform the procedures for initial registration as described in this subclause. 

After a maximum of 5 consecutive unsuccessful initial registration attempts, the MSC Server enhanced for ICS shall not 
automatically attempt any further initial registration for an implementation dependant time of at least: 
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a) the amount of time indicated in the Retry- After header field of the 4xx, 5xx or 6xx response received in response 
to the most recent registration request, if that header field was present; or 

b) 30 minutes, if the Retry- After header field was not present and the initial registration was automatically 
performed as a consequence of a failed reregistration; or 

c) 5 minutes, if the header field was not present and the initial registration was not performed as a consequence of a 
failed reregistration. 

6.3.3 Sending the REGISTER request 

The MSC Server enhanced for ICS shall send the REGISTER request as follows: 

1) if the MSC Server enhanced for ICS is located in the visited network, and local policy requires the application of 
IBCF capabilities in the visited network towards the home network, the MSC Server enhanced for ICS shall send 
the REGISTER request to an IBCF in the visited network. 

If the selected exit point: 

does not respond to the REGISTER request and its retransmissions by the MSC Server enhanced for ICS; or 
sends back a 3xx response or a 480 (Temporarily Unavailable) response to a REGISTER request; 

the MSC Server enhanced for ICS shall select a new exit point and forward the REGISTER request. 

NOTE 1 : The list of exit points can be either provisioned in the MSC Server enhanced for ICS or obtained as 
specified in IETF RFC 3263 [30]. 

NOTE 2: If the MSC Server enhanced for ICS sends the request to an IBCF in the visited network, the IBCF can 
determine the entry point of the home network, using the same mechanisms as described in NOTE 1 
above. In that case the MSC Server enhanced for ICS does not need to determine the entry point of the 
home network. 

2) determine the entry point of the home network and send the request to that entry point. 
If the selected entry point: 

does not respond to the REGISTER request and its retransmissions by the MSC Server enhanced for ICS; or 

sends back a 3xx response or a 480 (Temporarily Unavailable) response to a REGISTER request; 

the MSC Server enhanced for ICS shall select a new entry point and forward the REGISTER request. 

NOTE 3: The list of entry points can be either provisioned in the MSC Server enhanced for or obtained as 
specified in IETF RFC 3263 [30]. 

If the MSC Server enhanced for ICS fails to send the REGISTER request to any exit or entry point, the MSC Server 
enhanced for ICS shall abort the registration attempt. 

6.3.4 Subscription to tine registration-state event package 

Upon receipt of a 200 (OK) response to the initial registration, the MSC Server enhanced for ICS shall generate a 
SUBSCRIBE request in accordance with IETF RFC 3680 [33], with the following elements: 

a Request-URI set to a SIP URI that contains the default public user identity received in the 200 (OK) response 
to the REGISTER request; 

a From header field set to a SIP URI that contains the default public user identity received in the 200 (OK) 
response to the REGISTER request; 

a To header field set to a SIP URI that contains the default public user identity received in the 200 (OK) response 
to the REGISTER request; 

a Route header field set to values received in the Service-Route header field saved from the 200 (OK) response 
to the last registration. If the MSC Server enhanced for ICS is located in the visited network, and local policy 
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requires the application of IBCF capabilities in the visited network towards the home network, select an IBCF in 
the visited network and add the URI of the selected IBCF to the topmost Route header field; 

an Event header field set to the "reg" event package; 

an Expires header field set to a value higher than the Expires header field indicated in the 200 (OK) response to 
the REGISTER request; 

- a Contact header field set to the SIP URI of the MSC Server enhanced for ICS; 

a P-Asserted-Identity header field set a SIP URI that contains the default public user identity received in the 200 
(OK) response to the REGISTER request; 

a P-Charging-Vector header field with the icid parameter populated as specified in 3GPP TS 32.260 [27]; and 

a P-Access-Network-Info header field set as specified for the access network technology as specified in 
3GPPTS 24.229 [11]. 

Upon receipt of a 2xx response to the SIP SUBSCRIBE request, the MSC Server enhanced for ICS shall store the 
information for the established dialog and the expiration time as indicated in the Expires header field of the received 
response. 

The MSC Server enhanced for ICS shall automatically refresh the subscription for the reg event package for a 
previously registered public user identity for the period of time in which that registration remains active. The MSC 
Server enhanced for ICS shall refresh the subscription either 600 seconds before the expiration time if the initial 
subscription was for greater than 1200 seconds, or when half of the time has expired if the initial subscription was for 
1200 seconds or less. If a SUBSCRIBE request to refresh a subscription fails with a non-481 response, the MSC Server 
enhanced for ICS shall still consider the original subscription valid for the duration of the most recently known 
"Expires" value according to IETF RFC 3265 [32]. Otherwise, the MSC Server enhanced for ICS shall consider the 
subscription invalid and start a new initial subscription according to IETF RFC 3265 [32]. 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package with 
a state attribute "active", i.e. registered is received for one or more public user identities, the MSC Server enhanced for 
ICS shall 

1) store the indicated public user identities as registered; and 

2) for each public user identity indicated in the notification that contains a <pub-gruu> element or a <temp-gruu> 
element or both (as defined in IETF RFC 5628 [35]) store the value of those elements in association with the 
public user identity. 



6.3.5 Reregistration 



The MSC Server enhanced for ICS can perform the reregistration of a previously registered public user identity with its 
contact address at any time after the initial registration has been completed 

Unless the MSC Server enhanced for ICS has determined that a continued registration is not required, the MSC Server 
enhanced for ICS shall reregister an already registered public user identity if that subscriber is still registered to that 
VLR. The MSC Server enhanced for ICS shall register the already registered public user identity either 600 seconds 
before the expiration time if the previous registration was for greater than 1200 seconds, or when half of the time has 
expired if the initial subscription was for 1200 seconds or less, or when the MSC Server enhanced for ICS intends to 
update its capabilities according to IETF RFC 3840 [34]. 

On sending the REGISTER request for reregistration, the MSC Server enhanced for ICS shall populate headers as 
described in subclause 6.3.2. 

If the MSC Server enhanced for ICS fails to forward the REGISTER request, the MSC Server enhanced for ICS shall 
abort the reregistration attempt. 

NOTE: This will not affect the UE's CS domain registration status at the MSC Server enhanced for ICS or HSS or 
HLR. 

On receiving a 200 (OK) response to the REGISTER request, the MSC Server enhanced for ICS shall perform the 
actions defined for 200 (OK) response handling in subclause 6.3.2. 



£75/ 



3GPP TS 24.292 version 8.4.0 Release 8 1 9 ETSI TS 1 24 292 V8.4.0 (201 0-01 ) 

On receiving a 423 (Interval Too Brief) response to the REGISTER request, the MSC Server enhanced for ICS shall 
perform the actions defined for 423 (Interval Too Brief) response handling in subclause 6.3.2. 

On receiving a 408 (Request Timeout) response or 500 (Server Internal Error) response or 504 (Server Time-Out) 
response for a reregistration, the MSC Server enhanced for ICS shall perform the procedures for initial registration as 
described in subclause 6.3.2. 

When the timer F expires at the MSC Server enhanced for ICS, the MSC Server enhanced for ICS shall: 

1) select a different exit or entry point as described in subclause 6.3.3; and 

2) perform the procedures for initial registration as described in subclause 6.3.2. 

6.3.6 Deregistration 

6.3.6.1 S-CSCF initiated deregistration 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package on 
behalf of the UE, as described in subclause 6.3.4, including a <registration> element which was registered by the MSC 
Server enhanced for ICS with either: 

the state attribute set to "terminated" and the event attribute within the <contact> element belonging to this UE 
set to "rejected" or "deactivated"; or 

the state attribute set to "active" and the state attribute within the <contact> element belonging to this UE set to 
"terminated", and the event attribute within the <contact> element belonging to this UE set to "rejected" or 
"deactivated"; 

the MSC Server enhanced for ICS shall remove all stored information for these public user identities and remove these 
public user identities from the list of the public user identities that are registered for this user. In case of a "deactivated" 
event attribute, the MSC Server enhanced for ICS shall start the initial registration procedure as described in 
subclause 6.3.1. In case of a "rejected" event attribute, the MSC Server enhanced for ICS shall release all IMS dialogs 
related to those public user identities. 

6.3.6.2 MSC Server enhanced for ICS initiated deregistration 

The MSC Server enhanced for ICS initiated deregistration procedure consists of the MSC Server enhanced for ICS 
sending a REGISTER request on behalf of the UE upon receipt of any indication that the subscriber is no longer active 
at this MSC Server enhanced for ICS. On receiving Location Cancellation request, the MSC Server enhanced for ICS 
should delay sending the REGISTER request for deregistration for a specific time in order to ensure that the registration 
request from the target MSC Server arrives at the S-CSCF prior to the deregistration request from the source MSC 
Server. 

Prior to sending a REGISTER request for deregistration, the MSC Server enhanced for ICS shall release all IMS dialogs 
related to the public user identity that is going to be deregistered or to one of the implicitly registered public user 
identities. 

On sending a REGISTER request for deregistration, the MSC Server enhanced for ICS shall: 

1) set the Request-URI to the SIP URI of the domain name of the home network used to address the REGISTER 
request; 

2) set the From header field to the SIP URI that contains the public user identity to be deregistered; 

3) set the To header field to the SIP URI that contains the public user identity to be deregistered; 

4) set the Contact header field set to include the SIP URI containing the IP address or FQDN of the MSC Server 
enhanced for ICS in the hostport parameter. The MSC Server enhanced for ICS shall include a +sip. instance 
parameter containing the instance ID that was used during registration; 

5) set the Via header field to include the IP address or FQDN of the MSC Server enhanced for ICS in the sent -by 
field; 

6) set the Expires header field, or the expires parameter within the Contact header field, to the value of zero; and 
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7) send the request as specified in subclause 6.3.3. 

On receiving the 200 (OK) response to the REGISTER request, the MSC Server enhanced for ICS shall remove all 
registration details relating to this public user identity. 

NOTE: Other final responses than 200 (OK) might require the MSC Server enhanced for ICS to perform cleanup 
such as removing details related to that public user identity. The details of such actions are not specified 
in this version of the specification. 

The MSC Server enhanced for ICS shall consider any existing subscription to the reg event package cancelled (i.e. as if 
the MSC Server had sent a SUBSCRIBE request with an Expires header field containing a value of zero). 

6.4 sec AS 

The sec AS can obtain registration state information that it needs to implement ICS specific requirements from: 

a) any received third-party REGISTER request (e.g. including information contained in the body of the third-party 
REGISTER request) as specified in 3GPP TS 24.229 [11]; 

b) any received reg event package as specified in 3GPP TS 24.229 [1 1]; or 

c) the Sh interface as specified in 3GPP TS 29.328 [25] and 3GPP TS 29.329 [26]. 

NOTE: Obtaining registration state information from HSS using Sh interface does not allow the SCC AS to know 
the capabilities supported by the user registered UE(s), including the used IP-CAN(s). 



7 Roles for call origination 

7.1 Introduction 

This clause specifies the procedures for call origination for when an ICS UE originates a session, establishing the 
service control signalling path over Gm and when a non-ICS UE originates a session achieving IMS service control via 
an MSC server enhanced for ICS. The associated procedures for the SCC AS and MSC server enhanced for ICS are also 
specified in this clause. 

Subclause A.4 provides examples of signalling flows for call origination. 

7.2 ICS UE 

7.2.1 General 

This clause specifies the procedures for call origination by an ICS UE. 
Annex A.4 gives examples of signalling flows for call origination. 

7.2.2 ICS UE using Gm 

There are no ICS specific requirements for the origination of calls that may be subject to ICS. 

If ICS is enabled then when the ICS UE originates a CS call using Gm reference point, the ICS UE shall: 

a) send a SIP INVITE request towards the IM CN subsystems as specified in 3GPP TS 24.229 [11]. The ICS UE 
shall populate the SIP INVITE request as follows: 

i) include in the Contact header field: 

- a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [11] if a GRUU was received at 
registration; 
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- the feature tag g.3gpp.ics set to"" principal; and 

ii) the SDP payload proposing an audio stream over a circuit-switched bearer as described by draft-ietf-mmusic- 
sdp-cs [36], as follows: 

a "c=" line with the nettype portion set to "PSTN" and the addrtype portion and connection-address 
portions both set to "-"; 

an "m=" line with the media portion set to "audio", port portion set to "9", proto portion set to "PSTN" 
and fmt portion set to "-"; 

an a=setup attribute set to "active" 

an a=connection attribute set to "new"; and 

an indication that the related local preconditions for QoS as not met as specified in 3GPP TS 24.229 [11]. 

b) when the ICS UE receives a reliable Ixx provisional response from the network including a PSI DN number, the 
ICS UE shall send a CC SETUP message in accordance with 3GPP TS 24.008 [7] for 3GPP systems. The UE 
shall populate the CC SETUP message for 3GPP systems as follows: 

i) the called party BCD number information element set to the SCC AS PSI DN received in the SDP body of 
the Ixx provisional response, in the fmt portion of the "c=" line, appended to the "PSTN" nettype portion as 
described in draft- draft-ietf-mmusic-sdp-cs [36]; and 

c) when the CS resources are available to the UE, the ICS UE shall send an SDP offer including an indication that 
the related local preconditions for QoS for audio as met as specified in 3GPP TS 24.229 [11]. 

When the ICS UE originates a non-CS bearer call using Gm reference point, the ICS UE shall act in accordance with 

3GPPTS 24.229 [11]. 

7.2.3 ICS UE using CS 

The ICS UE shall implement the call origination towards SCC AS suitable for ICS via CS domain as specified in 
3GPP TS 24.008 [7] for 3GPP systems. 

7.3 MSC Server enhanced for ICS 

The MSC Server enhanced for ICS shall implement call origination towards the SCC AS as specified in 
3GPP TS 29.292 [24] with the following addition: 

the Contact header of the SIP INVITE request shall include the feature tag g.3gpp.ics set to "server". 

7.4 SCC AS 

7.4.1 General 

The following subclauses describe the procedures at the SCC AS for call origination. In such scenarios, the SCC AS 
serves the originating ICS UE. The SCC AS shall follow procedures specified in 3GPP TS 24.229 [11] with the 
additional procedures described in this specification in subclauses 7.4.2 and 7.4.3. These subclauses describe the 
procedures for the SCC AS when using service control over Gm and CS, respectively. 

7.4.2 SCC AS for service control over Gm 
7.4.2.1 CS bearer Is requested by the ICS UE 

When the SCC AS receives an initial SIP INVITE request from the ICS UE due to initial filter criteria, the SCC AS 
shall: 
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1) store the information received in the SIP INVITE request, including the Request-URI, P-Asserted-Identity 
header field, Accept header field, Call-ID header field. To and From header fields including tags. Contact header 
field including associated feature tags, Accept-Contact header field and the received non-audio SDP information. 

2) check if the SDP contains a "c=" line with nettype portion set to "PSTN" along with an "m=" line with media 
portion set to audio, port portion set to "9" and nettype portion set to "PSTN" along with an a=setup attribute set 
to "active"and an a=connection attribute set to "new" as described in draft-ietf-mmusic-sdp-cs [36]. If these are 
all present, the ICS UE is requesting that the media bearer is to be set up over the CS domain and the SCC AS 
shall send a SIP 183 (Session Progress) response towards the originating ICS UE in accordance with 

3GPP TS 24.229 [11] with the following additions: 

i) an SDP answer, in accordance with draft-ietf-mmusic-sdp-cs [36], containing a "c=" line with the nettype 
portion set to "PSTN" and with the addrtype portion set to "E164" and the fmt portion set to an E.164 number 
representing a SCC AS PSI DN. The SCC AS PSI DN that identifies the stored information in step 1) and 
associated with the SCC AS; 

ii) an a=setup attribute set to "passive" 

iii) an a=connection attribute set to "new"; and 

iv) indicate local preconditions not met. 

3) Wait for an initial SIP INVITE request from the CS domain with the Request-URI set to the allocated SCC AS 
PSI DN. 

4) When the SCC AS receives an initial SIP INVITE request from the CS domain the SCC AS shall check that the 
Request URI is set to a vaHd SCC AS PSI DN as allocated in the above step 2. If the SCC AS PSI DN is valid, 
the SCC AS shall: 

i) use the SCC AS PSI DN that was allocated in step 2 and correlate the previously stored information against 
this session with the incoming SIP INVITE request. 

ii) act as a routing B2BUA, and generate an initial SIP INVITE request and include the information received in 
the SIP INVITE received in step 1 with the following exceptions: 

a) if a Privacy type of "id" is received in the SIP INVITE request from the CS domain then the Privacy type 
shall be set to type of "id"; and 

b) an SDP offer with the media that combines the stored SDP offer from the ICS UE received in the SIP 
INVITE request from the ICS UE and the SDP offer received from the CS domain received in SIP 
INVITE request from the CS domain in accordance with the rules of IETF RFC 3264 [31]. 

Upon receiving a SIP 18x response from the terminating UE the SCC AS shall: 

1) send a SIP 18x response towards the ICS UE. If the receiving response includes an SDP answer, the SIP 18x 
response shall include an SDP answer, and use a different dialog from that of the first SIP 183(Session Progress) 
response sent by the AS; 

2) send a SIP 18x response towards the CS domain. 

The SDP answers shall be in accordance with rules for SDP answer as specified in IETF RFC 3264 [31]. 

When the SCC AS is aware of that preconditions are met on all legs the SCC AS shall send an UPDATE request 
towards the terminating UE indicating that local preconditions are met. 

Upon receiving a SIP 200 (OK) response from the terminating UE, the SCC AS shall send a SIP 200 (OK) response 
towards the ICS UE and CS domain. If the response includes an SDP answer, the AS shall send an SDP answer towards 
the ICS UE and towards the CS domain. The SDP answers shall be in accordance with rules for SDP answer as 
specified in IETF RFC 3264 [31]. 

When the SCC AS receives a SIP ACK request originated from an MSC server enhanced for ICS or from an MGCF and 
the ISC UE, the SCC AS shall respond to the initial SIP INVITE request with a final 200 (OK) response, on the same 
dialog on which the second 18x was sent to the ICS UE. 
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7.4.2.2 Non CS bearer is requested by the ICS UE 

When the SCC AS receives an initial SIP INVITE request due to initial filter criteria, which does not include a request 
for CS media, the SCC AS shall act as a routing B2BUA as described in 3GPP TS 24.229 [11]. 

7.4.3 SCC AS for service control over CS 

When the SCC AS receives SIP INVITE request due to originating IMRN, the SCC AS shall: 
NOTE 1 : Allocation of the IMRN is outside the scope of this specification. 

1) operate as an application server providing 3"* party call control, and specifically as an initiating B2BUA, as 
specified in subclause 5.7.5 of 3GPP TS 24.229 [11] for this request and all future requests and responses in the 
same dialog; 

2) set the Request-URI of the outgoing initial SIP INVITE request to a tel-URI which represents the original called 
party number of the call as initiated in the CS domain. The tel-URI may be available from information associated 
with the received IMRN or from the History-Info header field; 

3) set the To header field of the outgoing initial SIP INVITE request to a tel-URI which represents the original 
called party number of the call as initiated in the CS domain. The tel-URI may be available from information 
associated with the received IMRN or from the History-Info header field; 

4) if the SCC AS has received a History-Info header field indicating only one diversion, not include the History- 
Info header field; 

5) append the orig parameter to the S-CSCF URI included in the Route header field of the outgoing initial SIP 
INVITE request; and 

6) set the P-Asserted-Identity header field of the outgoing SIP INVITE request and to a tel-URI which represents 
the calling party number of the call initiated in the CS domain. This is either available from information 
associated against the received IMRN or is the value as received in P-Asserted-Identity header field of the 
incoming SIP INVITE request. 

NOTE 2: It can happen that the P-Asserted-Identity header field is not included in the incoming SIP INVITE 
request. 

The SCC AS should in the outgoing SIP requests and SIP responses include the same values as received in the 
incoming SIP requests and SIP responses in all other header fields with the exception given in this subclause and in 
subclause 5.7.5 of 3GPP TS 24.229 [8]. 

The SCC AS will handle the Privacy header field in the outgoing SIP INVITE request in the following way. The SCC 
AS shall either: 

if a Privacy header field is received in the incoming INVITE request, include the Privacy header field as 
received in the incoming INVITE request; or 

if a value is associated to IMRN and indicates that the presentation of the calling party number is restricted in the 
CS domain, include a Privacy header field with the value set to "id". 

On completion of the above procedure, the call is anchored in the SCC AS. 

NOTE 3: After completion of anchoring the call in SCC AS, the allocated IMRN is available for reuse. 



8 Roles for call modifcation initiated from the ICS UE 

8.1 Introduction 

This clause specifies call modification procedures initiated by an ICS UE for a call using a service control signalling 
path over Gm. The associated procedures for the ICS UE and the SCC AS are also specified in this clause; specifically, 
the procedure when a CS bearer is added or removed is specified. 
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8.2 ICS UE 

8.2.1 General 

This clause specifies the procedures for a UE when the call modification is initiated by an ICS UE. 

8.2.2 ICS UE is using Gm 

8.2.2.1 General 

This subclause specifies call modification procedure when a session is modified from an ICS UE using a service control 
signalling path over Gm; specifically, the procedure when a CS bearer is added or removed is specified. 

8.2.2.2 ICS UE adds a CS bearer 

If the UE decides to add a CS bearer to an existing session, the ICS UE shall act in accordance with subclause 7.2.2, 
except that a SIP re-INVITE request and its related responses shall be used instead of an initial SIP INVITE request. 

8.2.2.3 ICS UE adds voice media in PS domain 

If the ICS UE decides to add a voice media using the PS domain, the ICS UE shall apply the procedure in accordance 
with 3GPPTS 24.229 [11]. 

8.2.2.4 ICS UE adds a non-voice media in PS domain 

If the ICS UE decides to add non- voice media using the PS domain, the ICS UE shall apply the procedure in accordance 
with 3GPPTS 24.229 [11]. 

8.2.2.5 ICS UE removes a CS bearer 

When an ICS UE wants to remove a CS bearer the ICS UE shall 

a) send a SIP re-INVITE request or SIP UPDATE request towards the IM CN subsystems as specified in 

3GPP TS 24.229 [11]. The ICS UE shall populate the SIP INVITE request or SIP UPDATE request as follows: 

i) the request URI set to the contact address earlier received from the SCC AS; 

ii) include in the Contact header field: 

- a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [ 1 1 ] if a GRUU was received at 
registration; 

the feature tag g.3gpp.ics set to principal; 

b) set the CS bearer to not be used any longer by setting the port number to zero for the "m=" line with the proto 
portion set to "PSTN" as described in draft-ietf-mmusic-sdp-cs [36]; and 

c) when the ICS UE receives a reliable Ixx provisional response from the IM CN subsystem, the ICS UE shall 
release the resources in accordance with 3GPP TS 24.008 [8]. 

8.2.2.6 ICS UE removes PS media 

If the ICS UE decides to remove any media using the PS domain the ICS UE shall apply the procedure in accordance 
with 3GPPTS 24.229 [11]. 

8.3 MSC server enhanced for ICS 

No special procedure is required for call modification procedure at the MSC Server enhanced for ICS. 
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8.4 sec AS 

8.4.1 General 

This subclause specifies call modification procedure when a session is modified from an SCC AS using a service 
control signalling path over Gm; specifically, the procedure when a CS bearer is added or removed is specified. 

8.4.2 SCC AS actions when UE adds a CS bearer 

When the SCC AS receives a SIP re-INVITE request from the ICS UE indicating the addition of a CS bearer on an 
existing session, the SCC AS shall: 

1) check if the SDP offer in the received SIP INVITE request contains a "c=" line with nettype portion set to 
"PSTN" along with an "m=" line with media portion set to audio, port portion set to "9" and nettype portion set 
to "PSTN" along with an a=setup attribute set to "active"and an a=connection attribute set to "new"as described 
in draft-ietf-mmusic-sdp-cs [36]. If these are all present, the ICS UE is requesting that the media bearer is to be 
set up over the CS domain and the SCC AS shall send a SIP 183 (Session Progress) response towards the 
originating ICS UE in accordance with 3GPP TS 24.229 [11] with the following additions: 

a) include an SDP answer, in accordance with draft-ietf-mmusic-sdp-cs [36], containing a "c=" line with the 
nettype portion set to "PSTN" and with the addrtype portion set to "E164" and the fmt portion set to an 
E.164 number representing a SCC AS PSI DN. The SCC AS PSI DN is associated with the SCC AS and 
identifies the existing session; 

b) an a=setup attribute set to "passive" 

c) an a=connection attribute set to "new"; and 

d) indicate local preconditions not met for the media over CS bearer. 

2) Wait for an initial SIP INVITE request from the CS domain with the Request-URI set to the allocated SCC AS 
PSI DN; and 

3) When the SCC AS receives the initial SIP INVITE request from the CS domain the SCC AS shall check that the 
Request URI is set to a vaUd SCC AS PSI DN as allocated in the above step 2. If the SCC AS PSI DN is valid, 
the SCC AS shall: 

a) use the SCC AS PSI DN that was allocated to associate SCC-AS-PDN with the existing session and act as a 
routing B2BUA, and generate SIP INVITE request and include the following information: 

i) a Request-URI set to the contact address of the terminating ICS UE; and 

ii) in the SDP add the SDP offer received from the CS domain in accordance with the rules of. 
IETF RFC 3264 [31]. 

Upon receiving a SIP 18x response from the terminating UE the SCC AS shall send the SIP ISx response towards the 
ICS UE and the CS domain. If the response from the terminating UE includes an SDP answer, the AS shall send an 
SDP answer towards the originating UE and towards the CS domain. The SDP answers shall be in accordance with 
rules for SDP answer as specified in IETF RFC 3264 [31]. 

When the SCC AS is aware that preconditions are met on all legs, the SCC AS shall send an UPDATE request towards 
the terminating UE indicating that local preconditions are met. 

Upon receiving a SIP 200 (OK) response from the called party, the SCC AS shall send the SIP 200 (OK) response 
towards the ICS UE and CS domain. If the response includes an SDP answer, the AS shall send an SDP answer towards 
the ICS UE and towards the CS domain. The SDP answers shall be in accordance with rules for SDP answer as 
specified in IETF RFC 3264 [31]. When the SCC AS receives a SIP ACK request originated from an MSC Server 
enhanced for ICS or from an MGCF and the ISC UE, the SCC AS shall respond to the initial SIP INVITE request with 
a final 200 (OK) response. 
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8.4.3 sec AS adds media in tine PS domain 

The sec AS shall apply the procedure in accordance with 3GPP TS 24.229 [11]. 

9 Roles for call modifcation initiated towards an ICS 

UE 

9.1 Introduction 

This clause specifies call modification procedures initiated towards an ICS UE for a call using a service control 
signalling path over Gm. The associated procedures for the ICS UE and the SCC AS are also specified in this clause; 
specifically, the procedure when a CS bearer is added or removed is specified. 

9.2 ICS UE 

9.2.1 General 

This clause specifies the procedures for a UE when the call modification is initiated towards an ICS UE. 

9.2.2 ICS UE using Gm 

9.2.2.1 General 

This subclause specifies call modification procedure when a session is modified towards an ICS UE using a service 
control signalling path over Gm; specifically, the procedure when a CS bearer is added or removed is specified. 

9.2.2.2 ICS UE is offered a CS bearer 

When the ICS UE receives a SIP INVITE request on an existing session indicating a request for a CS bearer, the ICS 
UE shall apply the procedure in accordance with subclause 8.2.2.2. 

9.2.2.3 ICS UE is offered another media 

If the ICS UE is offered a voice media in the PS domain using Gm reference point, the ICS UE shall act as specified in 

3GPPTS 24.229 [11]. 

9.2.2.4 ICS UE is offered a voice media both in CS and PS domain 

If the ICS UE is offered a voice media both in the PS domain using Gm reference point and the CS domain using a 
service control signalling path over Gm, the ICS UE shall act as specified in subclause 10.2.2.4. 

9.2.2.5 SCC AS removes a CS bearer 

When the ICS UE receives a SIP INVITE request from the network containing SDP with an indication that the CS 
bearer will not be used any longer with the port number set to zero for the "m=" line with nettype portion set to "PSTN" 
as described in draft-ietf-mmusic-sdp-cs [36], the ICS UE shall release the CS bearer resources in accordance with 
3GPPTS 24.008 [8]. 

9.2.2.6 SCC AS removes PS media 

If the ICS UE is instructed to remove a media stream in the PS domain using Gm reference point, the ICS UE shall 
remove the media stream as specified in 3GPP TS 24.229 [11]. 
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9.3 MSC server enhanced for ICS 

No special procedure is required for call modification procedure at the MSC server enhanced for ICS. 

9.4 sec AS 

9.4.1 Terminating Access domain selection 

When the SCC AS receives on an existing session a SIP re-INVITE request or a SIP UPDATE request to add a voice 
stream towards the ICS UE the SCC AS shall 

perform Terminating Access Domain Selection (T-ADS) based upon criteria described in 3GPP TS 23.292 [6]; 

if T-ADS results in choosing to deliver all media in the PS domain, skip the following steps and continue with 
call termination in the IM CN subsystem as specified in subclause 9.4.3; and 

if T-ADS results in choosing to deliver media in the CS domain, and using Gm for service control, acting as a 
B2BUA, the SCC AS shall act in accordance with subclause 9.4.2. 

9.4.2 SCC AS adds a CS bearer 

When the SCC AS receives on an existing session a SIP re-INVITE request to add a voice stream towards the ICS UE 
the SCC AS shall 

1) allocate an SCC AS PSI DN associated with the SCC AS and the INVITE request from the originating UE;. 

2) create a SIP INVITE request based upon the request from the originating UE and include the following: 
i) the Request URI set to the earlier received contact address 

ii) an SDP offer based on the received SDP offer from the originator and including the following: 

in the SDP offer include an additional audio media "m=" line with media portion set to audio, port portion 
set to "9", proto portion set to "PSTN" and fmt portion set to"-"as described in draft-ietf-mmusic-sdp- 
cs [36]; 

in the SDP offer include, a "c=" line with the nettype portion set to "PSTN" and with the addrtype portion 
set to "E164" and the fmt portion set to an E. 164 number representing the SCC AS PSI DN allocated in 
step 1) in accordance with draft-ietf-mmusic-sdp-cs [36]; 

an a=setup attribute set to "passive"; 

an a=connection attribute set to "new"; 

an indication that preconditions are not met; and 

3) route the created SIP INVITE request towards the terminating ICS UE. 

When the SCC AS receives the initial SIP INVITE request from the CS domain, the SCC AS shall check that the 
Request URI is set to a valid SCC AS PSI DN as allocated in the above step 1. If the SCC AS PSI DN valid, the SCC 
AS shall: 

1) use the SCC AS PSI DN to correlate the SCC AS PSI DN against the incoming SIP INVITE request from the 
originating UE. 

2) create a response to the CS domain in accordance with 3GGP TS 24.229 [11], indicating local preconditions met 
and route towards the CS domain. 

When the AS has received the 18x response from the terminating ICS UE and the SIP INVITE request with the SCC 
AS PSI DN number from the CS domain, the SCC AS shall prepare an SDP answer to be sent to the originating UE. 
The SDP answer shall be based on the SDP answer received from the ICS UE and the SDP offer received from the CS 
domain. If the SDP offer from the CS domain includes more than one speech codecs the SCC AS shall delete the lowest 
priority speech codecs. The status line in the response sent to the originating UE shall be the same as received in the 18x 
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response from the terminating ICS UE. The SDP answer sent to the originating UE shall be in accordance with 
IETFRFC3264[31]. 

When the AS gets aware that the remote precondition is fulfilled on the leg towards the originating UE and on the leg 
towards the CS domain, the SCC AS shall send an UPDATE request to the terminating UE indicating that precondition 

is met. 

When the SCC AS receives precondition is met from t the leg from the CS domain the SCC AS shall 

1) send a 200 (OK) for the UPDATE request on the leg to the CS domain and 

2) send a 200 (OK) for the INVITE request on the leg to the CS domain. 

9.4.3 SCC AS adds PS media 

When the SCC AS receives an SDP offer on an existing session a request to add or modify a non-voice stream towards 
the ICS UE the SCC AS shall act in routing AS in accordance with 3GPP TS 24.229 [11]. 

9.4.4 SCC AS removes a CS bearer 

If the SCC- AS receives an SDP offer from the originating UE that indicates that voice stream is removed, the SCC AS 
shall send a SIP INVITE request towards the IM CN subsystems as specified in 3GPP TS 24.229 [1 1]. The SCC AS 
shall populate the SIP INVITE request as follows: 

the Request URI set to the contact address of the terminating ICS UE; and 

an indication that the CS bearer will not be used any longer by setting the port number to zero for the "m=" line 
with nettype portion set to "PSTN" as described in draft-ietf-mmusic-sdp-cs [36]. 



1 Roles for call termination 

10.1 Introduction 

This clause specifies the procedures for call termination to an ICS UE and a non-ICS UE. The following procedures 
describe Terminating Access Domain Selection at both the SCC AS and terminating ICS UE, to decide the service 
control type for the terminating side of the session. Service control signalling path over Gm for an ICS UE and IMS 
service control for a non ICS UE via an MSC server enhanced for ICS are specified. Procedures specific to the SCC AS 
and MSC server enhanced for ICS are also described. 

Subclause A.5 provides examples of signalling flows for call termination. 

10.2 ICSUE 
10.2.1 General 

This clause specifies the procedures for call termination by an ICS UE. 
Subclause A.5 gives examples of signalling flows for call termination. 



10.2.2 ICSUE using Gm 
10.2.2.1 General 

Subclause 10.2.2 describes the behaviour of the terminating ICS UE. 
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10.2.2.2 Call control over Gm and voice over IP bearer 

When the ICS UE receives a SIP INVITE request containing SDP for establishing a session using just an IP bearer the 
ICS UE shall establish this session in accordance with 3GPP TS 24.229 [11] with the following clarification: 

if the SIP INVITE request contains a Target-Dialog header field containing dialog parameters that correspond to 
an existing dialog (or a dialog in the process of being established) between the ICS UE and SCC AS the ICS UE 
shall treat the SIP INVITE request as another dialog that is part of the same session as the dialog, identified by 
the dialog parameters contained in the Target-Dialog header field. 

if the SIP INVITE request does not contain a Target-Dialog header field but there is an existing dialog (or a 
dialog in the process of being established) between the ICS UE and SCC AS the SCC AS shall check if the 
dialog parameters for this request correspond to the dialog parameters received in a Target-Dialog header field 
received on an existing dialog (or a dialog in the process of being established) between the ICS UE and SCC AS 
and if so then the ICS UE shall treat the SIP INVITE request as another dialog that is part of the same session as 
the dialog that the Target-Dialog header field was received on. 

NOTE: The second case is to cover the possibility that requests can arrive out of the order that they were sent. 

10.2.2.3 Call control over Gm and voice over CS bearer 

When the ICS UE receives a SIP INVITE request and the ICS UE terminates a CS call using the Gm reference point, 
the ICS UE shall: 

send a reliable Ixx provisional response towards the IM CN subsystems as specified in 3GPP TS 24.229 [11]. 
The UE shall populate the Ixx provisional response as follows: 

a) the SDP payload proposing an audio stream over a circuit-switched bearer as described by draft-ietf-mmusic- 
sdp-cs [36], as follows: 

a "c=" line with the nettype portion to "PSTN" and the addrtype portion and connection-address portions 
both set to "-"; 

an "m=" line with the media portion set to "audio", port portion set to "9", proto portion to "PSTN" and 
fmt portion set to "-";as described in draft-ietf-mmusic-sdp-cs [36] 

an a=setup attribute set to "active" 

an a=connection attribute set to "new"; and; 

b) an indication that the local preconditions for QoS as not met as specified in 3GPP TS 24.229 [11]. 

- send a CC SETUP message in accordance with 3GPP TS 24.008 [7] for 3GPP systems. The UE shall populate 
the CC SETUP message for 3GPP systems as follows: 

a) the called party BCD number information element set to the E.164 number obtained from the fmt portion 
received in the SDP body of the SIP INVITE request and included in the "c=" line with the nettype portion 
set to "PSTN" of the audio media, as described in draft-ietf-mmusic-sdp-cs [36] and the selected codec. 

when the resources are available to the UE, and if the UE has already received an indication from the origination 
side that related local preconditions for QoS as met on the originating side, shall send a 180 Ringing message 
and continue the call setup as specified in 3GPP TS 24.229 [11]. 

When the ICS UE receives a SIP INVITE request from the SCC AS indicating that the audio media may be transferred 
over either PS domain or CS domain, the ICS UE shall execute T-ADS to select an appropriate domain for the audio 
media bearer. Once the appropriate domain is selected by executing T-ADS, the ICS UE shall follow the procedures 
described in subclause 7.2.2 for PS procedures or subclause 7.2.4 for CS procedures to complete the rest of the session 
setup. 

1 0.2.2.4 Call control over Gm and T-ADS executed by the UE 

When the ICS UE receives, within an initial SIP INVITE request, an SDP Offer which allows the UE to select between 
using an RTP-based IP bearer or a CS bearer for an audio session, i.e. in which for the audio media line the following is 

set: 
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the transport protocol within the media hne to RTP-based IP bearer; 

the related connection line to an IP address; 

additional a-lines as defined in draft-ietf-mmusic-sdp-capability-negotiation [40], draft-garcia-mmusic-sdp-misc- 
cap [39], draft-ietf-mmusic-sdp-cs [36] and draft-ietf-mmusic-sdp-media-capabilities [41] indicating the 
following: 

a) the media capability attribute "mcap" set to "-"; 

b) the transport protocol capability attribute "tcap" set to "PSTN"; and 

c) the connection data capability attribute "ccap" set to "PSTN", indicating "E.164" as address type and the 
address set to the SCC AS PSI DN; 

and the ICS UE supports T-ADS execution, the ICS UE shall, 

if the UE in the response to the INVITE request includes a P-Access-Network-Info header field including an 
access-type field set to one of "3GPP-E-UTRAN-FDD" or "3GPP-E-UTRAN-TDD", the UE supports CSFB, 
and the UE is not responding with a SIP 3xx response, then the following applies, if the 

Voice_Domain_Preference_E_UTRAN leaf of the 3GPP IMS Management Object (see 3GPP TS 24.167 [8A]) 
is configured and is: 

a) set to "1" (i.e. "CS Voice only") and the NAS sublayer has indicated a successful NAS combined attach or 
TA update then the UE shall use the CS bearer for the related audio media stream; 

b) set to "1" and the NAS sublayer has not indicated a successful NAS combined attach or TA update, the UE 
shall send back a 606 (Not Acceptable) response; 

c) set to "2" (i.e. "CS Voice preferred, IMS PS Voice secondary") and the NAS sublayer has indicated a 
successful NAS combined attach or TA update then the UE shall use the CS bearer for the related audio 
media stream; 

d) set to "2" and the NAS sublayer has not indicated a successful NAS combined attach or TA update and the 
IMSVoPS indicator indicates voice is supported, then the UE shall use a RTP-based PS bearer for the related 
audio media stream; 

e) set to "2" and the NAS sublayer has not indicated a successful NAS combined attach or TA update and the 
IMSVoPS indicator indicates voice is not supported, then the UE shall send back a 606 (Not Acceptable) 
response; 

f) set to "3" (i.e. "IMS PS Voice preferred, CS Voice secondary") and the IMSVoPS indicator indicates voice is 
supported, then the UE shall use a RTP-based PS bearer for the related audio media stream; 

g) set to "3" and the IMSVoPS indicator indicates voice is not supported and the NAS sublayer has indicated a 
successful NAS combined attach or TA update, then the UE shall use CS bearer for the related audio media 
stream; 

h) set to "3" and the IMSVoPS indicator indicates voice is not supported and the NAS sublayer has not 
indicated a successful NAS combined attach or TA update, then the UE shall send back a 606 (Not 
Acceptable) response; 

i) set to "4" (i.e. "PS Voice only") and the IMSVoPS indicator indicates voice is supported, then the UE shall 
use a RTP-based PS bearer for the related audio media stream; or 

j) set to "4" and the IMSVoPS indicator indicates voice is not supported, then the UE shall send back a 606 
(Not Acceptable) response; 

if the UE in the response to the INVITE request includes a P-Access-Network-Info header field including an 
access-type field set to one of "3GPP-UTRAN-FDD" or "3GPP-UTRAN-TDD", and the UE is not responding 
with a SIP 3xx response, then the following applies, if the Voice_Domain_Preference_UTRAN leaf of the 3GPP 
IMS Management Object (see 3GPP TS 24.167 [8 A]) is configured and is: 

a) set to "1" (i.e. "CS Voice only"), then the UE shall use the CS bearer for the related audio media stream; 
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b) set to "2" (i.e. "CS Voice preferred, IMS PS Voice secondary") and the IMSVoPS indicator indicates voice is 
not supported, then the UE shall use the CS bearer for the related audio media stream; 

c) set to "2" (i.e. "CS Voice preferred, IMS PS Voice secondary") and the IMSVoPS indicator indicates voice is 
supported, then the UE should use the CS bearer for the related audio media stream or may use a RTP-based 
PS bearer for the related audio media stream; 

d) set to "3" (i.e. "IMS PS Voice preferred, CS Voice secondary") and the IMSVoPS indicator indicates voice is 
supported, then the UE should use a RTP-based PS bearer for the related audio media stream or may use the 
CS bearer for the related audio media stream; or 

e) set to "3" and the IMSVoPS indicator indicates voice is not supported, then the UE shall use CS bearer for 
the related audio media stream. 

if the UE in the response to the INVITE request includes a P-Access-Network-Info header field including an 
access-type field set to one of: 

1) "3GPP-E-UTRAN-FDD" or "3GPP-E-UTRAN-TDD", and the Voice_Domain_Preference_E_UTRAN leaf 
of the 3GPP IMS Management Object (see 3GPP TS 24.167 [8A]) is not configured; or 

2) "3GPP-UTRAN-FDD" or "3GPP-UTRAN-TDD", and the Voice_Domain_Preference_UTRAN leaf of the 
3GPP IMS Management Object (see 3GPP TS 24.167 [8A]) is not configured, 

and: 

NOTE 1 : The UE decides based on local configuration and network conditions whether to use for the related audio 
media stream an IP connection, RTP-based IP bearer or a CS bearer. 

a) if the IMSVoPS indicator indicates voice is supported, then the UE can use a RTP-based PS bearer for the 
related audio media stream; 

b) if the IMSVoPS indicator indicates voice is not supported, then the UE shall: 

I) not use this access technology for a RTP-based PS bearer for the related audio media stream (e.g. using a 
SIP 3xx response); or 

II) send back a 606 (Not Acceptable) response; 

if the UE in the response to the INVITE request includes a P-Access-Network-Info header field including an 
access-type field set to "3GPP-GERAN", and the IMSVoPS indicator is not supported or indicates voice is not 
supported then the UE shall not use this access technology for a RTP-based PS bearer for the related audio media 
stream: 

NOTE 2: The UE decides based on local configuration and network conditions whether to use for the related audio 
media stream an IP connection, RTP-based IP bearer or a CS bearer. 

a) not use this access technology for a RTP-based PS bearer for the related audio media stream (e.g. using a SIP 
3xx response); or 

b) send back a 606 (Not Acceptable) response; 

if the UE in the response to the INVITE request includes a P- Access-Network-Info header field including an 
access-type field not set to one of "3GPP-GERAN", "3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", "3GPP-E- 
UTRAN-FDD", or "3GPP-E-UTRAN-TDD", based on local configuration and network conditions, decide 
whether to use for the related audio media stream an IP connection RTP-based IP bearer or a CS bearer. 

If the ICS UE decides to use a IP connection or RTP-based IP bearer, the ICS UE shall proceed as described in 
subclause 10.2.2.2 and in addition indicate that the IP connection or RTP-based IP bearer is used within the SDP answer 
in accordance with draft-ietf-mmusic-sdp-capability-negotiation [40]. 

If the ICS UE decides to use a CS bearer, the ICS UE shall proceed as described in subclause 10.2.2.3 and in addition 
indicate that the CS bearer is used within the SDP answer in accordance with draft-ietf-mmusic-sdp-capability- 
negotiation [40]. 
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10.2.3 ICSUE using CS 



An ICS UE shall implement the call termination suitable for ICS via CS domain as specified in 3GPP TS 24.008 [7] for 
3GPP systems. 

10.2.4 CS fallback 

On the reception of an SIP INVITE request including an SDP body indicating an audio that can not be served via the 
current PS connectivity, the ICS UE shall send back a 488 (Not Acceptable Here) response without an SDP body. 

NOTE: As an example the UE responds with a 488 (Not Acceptable Here) response when the ICS UE is unable to 
support the full duplex speech component of a session using the attached PS network or the attached PS 
network does not support or allow the full duplex speech component of a session. 

1 0.3 MSC Server enhanced for ICS 

When the MSC Server enhanced for ICS receives an initial SIP INVITE request from the IM CN subsystem, the MSC 
Server enhanced for ICS shall return a 488 (Not Acceptable Here) response as described in 3GPP TS 24.229 [11] if the 
SIP INVITE request includes an SDP offer which does not contain an acceptable audio codec. 

The MSC Server enhanced for ICS shall implement call termination as specified in 3GPP TS 29.292 [24]. 

10.4 sec AS 

10.4.1 General 

The following subclauses describe the procedures at the SCC AS for call termination. In such scenarios, the SCC AS 
serves the terminating ICS UE. The SCC AS shall follow procedures specified in 3GPP TS 24.229 [11] with the 
additional procedures described in the subsequent subclauses. These subclauses describe the procedures for the SCC AS 
when using service control over Gm and CS, respectively. 

10.4.2 Terminating Access Domain Selection 

When the SCC AS serving the terminating ICS UE receives an initial SIP INVITE request due to initial filter criteria, 
the SCC AS shall perform Terminating Access Domain Selection (T-ADS) based upon criteria described in 
3GPP TS 23.292 [6]. Depending on the T-ADS result, the SCC AS shall: 

1) if T-ADS results in choosing to deliver all media in the PS domain (request was delivered due to terminating 
IMRN or due to iFC), then follow the SCC AS procedures as defined in subclause 10.4.3; 

2) if T-ADS results in choosing to deliver media in the CS domain, and using CS domain service control, the SCC 
AS: 

a) if for the related public user identity a registration from an MSC Server enhanced for ICS exists, follow the 
SCC AS procedures as defined in subclause 10.4.5; and 

b) if for the related public user identity no registration from an MSC Server enhanced for ICS exists, follow the 
SCC AS procedures as defined in subclause 10.4.7; 

3) if T-ADS results in choosing to deliver media in the CS domain, and using Gm for service control, follow the 
SCC AS procedures defined in subclause 10.4.4; and 

4) if T-ADS results in allowing the ICS UE to execute T-ADS to select an appropriate domain for the audio media 
bearer, the SCC AS shall create a SIP INVITE request based upon the incoming request including containing 
within the SDP offer with an RTP-based IP bearer and an alternative circuit-switched bearer as described in 
subclause 10.4.6 for the ICS UE to execute T-ADS. 
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1 0.4.3 sec AS for call termination in IM CN 

When the SCC AS serving the terminating ICS UE receives an initial SIP INVITE request due to initial filter criteria 
and the T-ADS results in choosing to deliver media in the PS domain, the SCC AS shall act as a B2BUA, and 

if multiple contacts are registered in the PS domain and the T-ADS chooses to establish different media types 
using different IP-CANs, the SCC AS shall for each selected PS domain IP-CAN create a SIP INVITE request 
in accordance with 3GPP TS24.229 [2] and shall include, in this request; 

i) an Accept-Contact header field containing the g.3gpp.accesstype media feature tag containing the value 
associated at registration with the selected PS domain IP-CAN and the media feature tag g.3gpp.ics 
containing the value "principal" along with the parameters "require" and "explicit"; 

NOTE 1: The SSC AS can determine which g.3gpp.accesstype media feature tag values to use by taking into 
account the access-type and access-class of the P-Access-Network-Info header and the value of the 
media feature tag gjgpp.accesstype . The values in the 3gpp.accesstype media feature tag does not 
necessarily always identify an IP -CAN. 

NOTE 2: It is possible that a handover between different IP-CANs can take place without a reregistration of the UE 
and corresponding update of access-type and access-class (e.g. from "3GPP-UTRAN" to "3GPP-E- 
UTRAN"). The SCC-AS needs to take this possibility into account when determining the IP-CAN to use. 

ii) if an existing leg for this session already exists or is in the process of being established between the SCC AS 
and the ICS UE using a different IP-CAN then a Target-Dialog header field containing the dialog parameters 
for that existing dialog between the SCC AS and the ICS UE; and 

NOTE 3: The SCC AS includes a Target-Dialog header field in the SIP INVITE request so that the ICS UE can 
correlate different requests as part of the same session. 

iii) SDP for the media type(s) selected to be established using this IP-CAN. 

if multiple contacts are registered in the PS domain and the T-ADS chooses to establish all the media types over 
the same IP-CAN, the SCC AS shall create a SIP INVITE request in accordance with 3GPP TS24.229 [2] and 
shall include, in this request: 

i) an Accept-Contact header field containing the g.3gpp.accesstype media feature tag containing the value 
associated at registration with the selected PS domain IP-CAN and the media feature tag g.3gpp.ics 
containing the value "principal" along with the parameters "require" and "explicit"; 

NOTE 4: The SSC AS can determine which g.3gpp.accesstype media feature tag values to use by taking into 
account the access-type and access-class of the P-Access-Network-Info header and the value of the 
media feature tag g.3gpp.accesstype . The values in the 3gpp.accesstype media feature tag does not 
necessarily always identify an IP -CAN. 

NOTE 5: It is possible that a handover between different IP-CANs can take place without a reregistration of the UE 
and corresponding update of access-type and access-class (e.g. from "3GPP-UTRAN" to "3GPP-E- 
UTRAN"). The SCC-AS needs to take this possibility into account when determining the IP-CAN to use. 

ii) if an existing leg for this session already exists or is in the process of being established between the SCC AS 
and the ICS UE using a different IP-CAN then a Target-Dialog header field containing the dialog parameters 
for that existing dialog between the SCC AS and the ICS UE; and 

NOTE 6: The SCC AS includes a Target-Dialog header field in the SIP INVITE request so that the ICS UE can 
correlate different requests as part of the same session. 

iii) SDP for all the media types contained in the initial SIP INVITE request. 

if only a single contact is registered in the PS domain the SCC AS shall create a SIP INVITE request in 
accordance with 3GPP TS24.229 [2] and shall include, in this request: 

i) an Accept-Contact header field containing the media feature tag g.3gpp.ics containing the value "principal" 
along with the parameters "require" and "explicit"; and 

ii) SDP for all the media types contained in the initial SIP INVITE request. 
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If the SCC-AS receives a 488 (Not Acceptable Here) response, not including any SDP body or including an SDP body 
without an m-line indicating audio, the SCC-AS may follow the procedures in subclause 10.4.5 or subclause 10.4.7. 

1 0.4.4 sec AS for call control over Gm and voice over CS 

When the SCC AS serving the terminating ICS UE receives an initial SIP INVITE request due to initial filter criteria 
and the T-ADS results in choosing to deliver media in the CS domain, the SCC AS shall act as a B2BUA, the SCC AS 
shall: 

1) allocate an SCC AS PSI DN associated with the SCC AS and the SIP INVITE request from the originating UE; 

2) create a SIP INVITE request and include: 

a) a Request-URI set to the value of the Request-URI as received in the incoming SIP INVITE request; 

b) a dedicated Accept-Contact header field with a media feature tag with the value g.3gpp.ics set to principal 
and append "require" and "explicit"; 

NOTE 1 : Other feature tags can also be included in the dedicated Accept-Contact header field if the feature tags 
have the same requirements on the "explicit" and "require" parameter. 

bl)an Accept-Contact header field with the values received in the Accept-Contact header field in the incoming 
SIP INVITE except for any g.3gpp.ics media feature tags; and 

NOTE 2: According to IETF RFC 3841 [35A] when the value of the "explicit" and "require" parameters are 
different for feature tag values they will be placed in separate Accept-Contact header fields. 

c) an SDP offer based on the received SDP from the originator and including the following: 

i) in the SDP offer towards the terminating ICS UE, include an additional media line with media portion set 
to audio, port portion set to "9", proto portion set to "PSTN", and fmt portion set to "-";as described in 
draft-ietf-mmusic-sdp-cs [36]; 

ii) a media level "c=" line, with the nettype portion set to "PSTN" and with the addrtype portion set to 

"E164" and the fmt portion set to an E.164 number representing the SCC AS PSI DN allocated in step 1) 
in accordance with draft-ietf-mmusic-sdp-cs [36]; 

iii) an a=setup attribute set to "passive" 

iv) an a=connection attribute set to "new"; 

v) codecs based on local policy and the received SDP offer from the originating UE; and 

vi) an indication that preconditions are not met; and 

3) route the created SIP INVITE request towards the terminating ICS UE. 

When the SCC AS receives a SIP INVITE request from the CS domain, the SCC AS shall check that the Request URI 
is set to a valid SCC AS PSI DN as allocated in the above step 1. If the SCC AS PSI DN is valid, the SCC AS shall: 

1) use the SCC AS PSI DN and correlate the SCC AS PSI DN against the incoming SIP INVITE request from the 
originating UE; and 

2) create a response in accordance with 3GPP TS 24.229 [11], indicating local preconditions met and route towards 
CS domain. 

Afterwards, when the SCC AS receives a 18x response, the SCC AS shall prepare an SDP answer to be sent to the 
originating UE. The SDP answer shall be based on the SDP answer received from the ICS UE and the SDP offer 
received from the CS domain. If the SDP offer from the CS domain includes more than one speech codecs the SCC AS 
shall delete the lowest priority speech codecs. The status line in the response sent to the originating UE shall be the 
same as received in the 18x response from the terminating ICS UE. The SDP answer sent to the originating UE shall be 
in accordance with IETF RFC 3264 [31]. 

When the SCC AS receives a 18x response prior to the related SIP INVITE request from the CS domain, the SCC AS 
shall wait until the SIP INVITE request from the CS domain is received. 
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When the AS gets aware that the remote precondition is fulfilled on the leg towards the originating UE and on the leg 
towards the CS domain, the SCC AS shall send an UPDATE request to the terminating UE indicating that precondition 
is met. 

When the SCC AS receives preconditions are met on the leg from the CS domain the SCC AS shall 

1) send a 200 (OK) for the SIP UPDATE request on the leg to the CS domain; and 

2) send a 200 (OK) for the SIP INVITE request on the leg to CS domain. 

1 0.4.5 SCC AS for call termination ICS Enhanced MSC Server 

The SCC AS shall act as a B2BUA, the SCC AS shall create a SIP INVITE request in accordance with 
3GPP TS 24.229 [11] with the following information; 

1) shall set the Request-URI to the value of the Request-URI as received in the incoming SIP INVITE request; and 

2) include in Accept-Contact header fields: 

the values received in the Accept-Contact header field(s) in the incoming SIP INVITE request except for any 
g.3gpp.ics media feature tags 

a media feature tag with the value g.3gpp.ics set to server appended with the value "explicit" and "require". 

NOTE: According to IETF RFC 3841 [35A] when the value of the "explicit" and "require" parameters are 
different for feature tag values they will be placed in separate Accept-Contact header fields. 

1 0.4.6 SCC AS allowing UE to execute T-ADS 

When the SCC AS serving the terminating ICS UE receives an initial SIP INVITE request due to initial filter criteria 
and the T-ADS results in allowing the ICS UE to execute T-ADS, the SCC AS shall act as a B2BUA, the SCC AS shall: 

1) allocate an SCC AS PSI DN associated with the SCC AS and the SIP INVITE request from the originating UE; 

2) create a SIP INVITE request and include the following: 

a) set the Request-URI to the value as received in the Request-URI in the incoming SIP INVITE request; 

b) a dedicated Accept-Contact header field a media feature tag with the value g.3gpp.ics set to principal 
appended with the value "explicit" and "require"; 

NOTE 1 : Other feature tags can also be included in the dedicated Accept-Contact header field if the feature tags 
have the same requirements on the "explicit" and "require" parameter. 

bl) an Accept-Contact header field with media feature tag values received in the Accept-Contact header field(s) 
in the incoming SIP INVITE request except for any g.3gpp.ics media feature tags; and 

NOTE 2: According to IETF RFC 3841 [35A] when the value of the "explicit" and "require" parameters are 
different for feature tag values they will be placed in separate Accept-Contact header fields. 

c) within the SDP offer based on the received SDP from the originator, for every media line indicating audio set 
the following: 

i) transport protocol within the media line to RTP -based IP bearer; 

ii) related connection line to the value as received from the originator; and 

iii) additional a-lines as defined in draft-ietf-mmusic-sdp-capability-negotiation [40], draft-garcia-mmusic- 
sdp-misc-cap [39], draft-ietf-mmusic-sdp-cs [36] and draft- ietf-mmusic-sdp-media-capabilities [41] 
indicating that: 

the required capability negotiation extensions attribute "creq" set to "med-vO" and "ccap-vO", 
indicating that the relevant SDP capability negotiation mechanisms must be supported by the 
terminating UE in order to initiate T-ADS; 
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the media capability attribute "mcap" set to "-"; 

the transport protocol capability attribute "tcap" set to "PSTN"; 

the connection data capability attribute "ccap" set to "PSTN", indicating "E.164" as address type and 
the el64-address portion set to an E.164 number representing the SCC AS PSI DN allocated in step 
1). The SCC AS PSI DN identifies the stored information and is associated with the SCC AS; 

the related preconditions of the originating side set to not met; and 

NOTE 3: In the case when the UE chooses to use the CS bearer, the resources are not available in the MGCF. 

Therefore, regardless on the current status of the resource reservation at the originating side, the SCC AS 
sets the preconditions to not met. 

3) route the created SIP INVITE request towards the terminating ICS UE. 

Upon receipt of a SIP response to this SIP INVITE request, including an SDP answer indicating that the UE has chosen 
the RTP-based IP bearer, the SCC AS shall proceed in accordance with 3GPP TS 24.229 [11]. 

When the SCC AS receives a SIP INVITE request from the CS domain, the SCC AS shall check that the Request URI 
is set to a valid SCC AS PSI DN as allocated in the above step 1 and proceed as defined in subclause 10.4.5. 

When the SCC AS has received the 18x response from the terminating ICS UE, including an SDP answer indicating 
that the UE has chosen the CS bearer, the SCC AS shall proceed as defined in subclause 10.4.5. 

If the SCC-AS receives a 488 (Not Acceptable Here) response, not including any SDP body or including an SDP body 
without an m-line indicating audio, the SCC-AS may follow the procedures in subclause 10.4.7 or subclause 10.4.5. 

1 0.4.7 SCC AS for call termination over CS to non-ICS UE 

When the SCC AS serving the terminating non ICS UE receives an initial SIP INVITE request due to the initial filter 
criteria, the SCC AS may select to breakout to the CS domain. 

Therefore the SCC AS retrieves via procedures as defined in subclause 6.4 the correlation MSISDN associated with the 
private user identity associated with the public user identity which is the served party of the session. The SCC AS shall, 
based on the correlation MSISDN, fetch a CSRN for routing the call to the CS domain. To perform CS breakout, the 
SCC AS shall act as B2BUA and shall create the SIP INVITE in accordance to the procedures in 3GPP TS 24.229 [11] 
with the headers as follows; 

1) set the Request-URI of the outgoing SIP INVITE request to the CSRN; and 

2) set the To header field of the outgoing SIP INVITE request to the CSRN; 

NOTE: How the CSRN gets selected by the SCC AS is out of the scope of this specification. 



1 1 Roles for session release 
11.1 Introduction 

This clause specifies session release procedures for when an ICS UE releases a session using a service control 
signalling path over Gm and when a non-ICS UE has IMS service control via an MSC server enhanced for ICS. The 
associated procedures for the SCC AS are also specified in this clause; specifically, the CS bearer release procedures 
when using Gm are described. The clause also specifies the SCC AS procedures when it detects the loss of service 
control signalling path over Gm. The session release procedures specific to an MSC server enhanced for ICS are also 
described. 
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11.2 ICSUE 

11.2.1 General 

This clause specifies the procedures for session release by an ICS UE. 

11.2.2 ICSUE using Gm 

The ICS UE shall support session release suitable for ICS via Gm reference point as specified in 3GPP TS 24.229 [11]. 

If the ICS UE uses a CS bearer, the UE shall release the resources in accordance with 3GPP TS 24.008 [7] for 3GPP 
systems, to release the CS bearer. 

NOTE: The order of releasing the CS or PS resources is an implementation issue. 

11.2.3 ICSUE using CS 

The ICS UE shall implement the bearer release towards SCC AS suitable for ICS via CS domain in accordance with 
3GPP TS 24.008 [7] for 3GPP systems. 

1 1 .3 MSC Server enhanced for ICS 

The MSC Server enhanced for ICS shall implement session release as specified in 3GPP TS 29.292 [24]. 

1 1 .4 SCO AS 

11.4.1 General 

The following subclauses describe the procedures at the SCC AS for session release. In such scenarios, the SCC AS 
serves the terminating ICS UE. The SCC AS shall follow procedures specified in 3GPP TS 24.229 [11] with the 
additional procedures described in this specification in subclauses 11.4.2 and 11.4.3. These subclauses describe the 
procedures for the SCC AS when using service control over Gm and CS, respectively. 

1 1 .4.2 SCC AS for service control over Gm 

When the SCC AS receives a SIP BYE request the SCC AS shall: 

1) determine if the SIP BYE request was originated due to release of a service control session or if the SIP BYE 
requested was originated in the CS domain as a result of ICS UE bearer release procedures; and 

2) if the SIP BYE request was received from an endpoint involved in the session to be released, this indicates a 
user's desire to release the service control session forward the SIP BYE request towards the other endpoint 
involved in the session. 

The SCC AS distinguishes the SIP BYE requests generated by the MGCP and the SIP BYE requests from the ICS UE 
by the associated dialog IDs. 

When the SCC AS receives a SIP BYE request from the ICS UE, the SCC AS shall: 

forward the SIP BYE request towards the remote leg in accordance with the procedures defined in 
3GPPTS 24.229 [11]; and 

if the CS bearer is not used by any other session, send a SIP BYE request towards the MGCF, in accordance with 
the procedures defined in 3GPP TS 24.229 [1 1], to release the CS bearer. 

When the SCC AS receives a SIP BYE request from the MGCF, the SCC AS shall do the following for every session 
associated with the ICS UE which has a CS bearer: 
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if the session includes other PS media in addition to the CS media, the SCC AS shall send a SIP re-INVITE or a 
SIP UPDATE request towards 

the access leg, removing the CS media by setting the port number to zero for the "m=" line set to "PSTN" as 
described in d draft-ietf-mmusic-sdp-cs [36]; and 

the remote leg, removing the corresponding audio media by setting the port number to zero; and 

if the session only contains CS media, the SCC AS shall send a SIP BYE request towards both the access and 
remote legs in accordance to the procedures defined in 3GPP TS 24.229 [11]. 

1 1 .4.3 SCC AS procedure upon loss of Gm service control 

If the SCC AS detects the ICS UE is not reachable over Gm service control, the SCC AS shall for every held session 
associated with the ICS UE send a SIP BYE request towards the other UE involved in the session in accordance with 
the procedures defined in 3GPP TS 24.229 [11]. 

NOTE: The exact mechanism for detecting loss of Gm by SCC AS is implementation dependent. 



12 Supplementary service invocation for ICS 

12.1 Supplementary service invocation for an ICS UE with IMS 
sessions using CS bearer 

12.1.1 Overview 

When the CS bearer is used for the media of the IMS Multimedia Telephony service, see 3GPP TS 22.173 [2], the 
procedures specified in this clause apply. 

12.1.2 Use of Gm reference point 

1 2.1 .2.1 Line ID Services (DIP, OIR, TIP, TIR) 

The procedures as defined in 3GPP TS 24.607 [14] and 3GPP TS 24.608 [15] apply with the addition of the SCC AS 
combining the description of the CS bearer with the service control signalling communicated over the Gm reference 
point as specified in subclause 7.4.2. 

12.1.2.2 Communication Diversion Services 

The procedures as defined in 3GPP TS 24.604 [12] apply with the addition of the SCC AS combining the description of 
the CS bearer with the service control signalling communicated over the Gm reference point as specified in 
subclause 7.4.2. 

12.1.2.3 Communication Barring 

The procedures as defined in 3GPP TS 24.611 [17] apply with the addition of the SCC AS combining the description of 
the CS bearer with the service control signalling communicated over the Gm reference point as specified in 
subclause 7.4.2. 

12.1.2.4 Communication Hold/Resume 

Invocation of Communication HOLD service for ICS UE using Gm reference point shall be as described in 
3GPPTS 24.610 [16]. 

Upon receiving the re-INVITE request describe in subclause 4.5.2. 1 of 3GPP TS 24.610 [16], which indicates that 
media streams shall be held, the SCC AS shall: 
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1) generate a new SDP offer that contains "inactive" attribute for the media streams that shall be put on held; 

2) send the SDP offer in an UPDATE (or re-INVITE) request towards the MGCF in order to inactive RTP media; 

Upon receiving the re-INVITE request describe in subclause 4.5.2. 1 of 3GPP TS 24.610 [16], which indicates that 
media streams shall be resumed, the SCC AS shall: 

1) send a re-INVITE request without SDP towards the MGCF. 

2) after receiving a 200 (OK) response with SDP offer from the MGCF, send another re-INVITE request with the 
SDP offer to the held UE. 

3) after receiving a 200 (OK) response with SDP answer from the held UE, send an ACK request with the SDP 
answer to the MGCF. 

1 2.1 .2.5 Explicit Communication Transfer 

Invocation of ECT service for ICS UE using Gm reference point shall be as described in 3GPP TS 24.629 [19] for a 
transferor UE, transferee UE, and transfer target UE. 

In the case of ICS UE as transferee, upon receiving an INVITE request from the transferee, the SCC AS shall: 

1) send a re-INVITE request without SDP to MGCF; 

2) after receiving a 200 (OK) response with SDP offer from the MGCF; 

3) initiate an INVITE request with the SDP offer to the transfer target; 

4) if, within a specific time, a response with an SDP answer from the transfer target is not received, send an ACK 
request to the MGCF with an SDP answer and repeat steps 1) and 2). The SDP answer shall contain the same 
media types as the SDP offer received from the MGCF; 

5) after receiving a response with SDP answer from the transfer target, send an ACK request with the SDP answer 
to the MGCF. 

12.1.2.6 Conferencing 

Invocation of conferencing service for ICS UE using Gm reference point shall be as described in 3GPP TS 24.147 [8]. 

12.1.2.7 Communication Waiting 

The procedures defined in 3GPP TS 24.615 [18] apply for invocation of Communication Waiting. The SCC AS shall 
update the session characteristics upon the existing session being put on hold or released, according to the procedures 
defined in subclauses 12.1.2.4 or 11.4.2, respectively. 

In the case that a CS bearer shall be established for the waiting session, procedures described in subclause 10.4 shall be 
applied to the session. 

12.1.4 When use of Gm reference point is not possible due to VPLMN 
limitations 

1 2.1 .4.1 When attached to an MSC Server enhanced for ICS 

Procedures specified in subclause 12.2 Supplementary service invocation for an ICS UE with IMS sessions using CS 
bearer apply. 

1 2.1 .4.2 When attached to an MSC Server not enhanced for ICS 

Procedures specified in clause 12.3 Supplementary service invocation for non ICS UE when attached to an MSC Server 
not enhanced for ICS apply. 
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12.2 Supplementary service invocation using the IVISC Server 
enhanced for ICS 

12.2.1 Line ID Services (OIP, OIR, TIP, TIR) 

Invocation of line ID services at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.607 [14] and 
3GPP TS 24.608 [15] for an originating UE and a terminating UE with the following exception: 

the MSC Server enhanced for ICS shall also apply the interworking procedures as specified in 
3GPP TS 29.292 [24] for line ID services. 

12.2.2 Communication Diversion (CDIV) Services 

12.2.2.1 General 

The following exception applies to the invocation of all CDIV services at the MSC Server enhanced for ICS acting as a 
diverting UA on behalf of the UE: 

the MSC Server enhanced for ICS shall not support the user subscription option of "served user receives 
indication that a communication has been forwarded (indication of communication diversion to the diverting 

user)". 

12.2.2.2 Communication Forwarding Unconditional (CFU) 

Invocation of CFU at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.604 [12] for an originating 
UA, diverted to UA and diverting UA. 

12.2.2.3 Communication Forwarding Busy (CFB) 

Invocation of CFB at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.604 [12] for an originating 
UA, diverted to UA and diverting UA with the following exception: 

for user determined user busy, invocation of CFB at the MSC Server enhanced for ICS acting as a diverting UA 
shall also apply the interworking procedures as specified in 3GPP TS 29.292 [24] for CFB. 

12.2.2.4 Communication Forwarding No Reply (CFNR) 

Invocation of CFNR at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.604 [12] for an 
originating UA, diverted to UA and diverting UA. 

12.2.2.5 Communication Forwarding on Not Logged-in (CFNL) 

Invocation of CFNL at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.604 [12] for an 
originating UA, diverted to UA and diverting UA. 

12.2.2.6 Communication Deflection (CD) 

Invocation of CD at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.604 [12] for an originating 
UA, diverted to UA and diverting UA with the following exception: 

invocation of CD at the MSC Server enhanced for ICS acting as a diverting UA shall also apply the interworking 
procedures as specified in 3GPP TS 29.292 [24] for CD. 

12.2.2.7 Communication Forwarding on Subscriber Not Reachable (CFNRc) 

Invocation of CFNRc at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.604 [12] for an 
originating UA, diverted to UA and diverting UA with the following exception: 
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invocation of CFNRc at the MSC Server enhanced for ICS acting as a diverting UA shall also apply the 
interworking procedures as specified in 3GPP TS 29.292 [24] for CFNRc. 

12.2.2.8 Communication Diversion Notification (CDIVN) 

The default behaviour at the MSC Server enhanced for ICS is to not issue a subscription for CDIVN. 

NOTE: The MSC Server can decide, for example, to subscribe to CDIVN as specified in 3GPP TS 24.604 [12] as 
an operator option, but such interworking is outside the scope of the present document. 

12.2.2.9 Diversion notifications to originating users 

Diversion notifications to originating users shall be supported at the MSC Server enhanced for ICS as described in 

3GPPTS 29.292 [24]. 

12.2.3 Communication Barring (CB) 

Invocation of CB at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.61 1 [17] for an originating 
and destination UE with the following exception: 

the MSC Server enhanced for ICS shall also apply interworking procedures as specified in 3GPP TS 29.292 [24] 
for CB. 

12.2.4 Communication Hold/Resume 

Invocation of Hold and Resume at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.610 [16] for 
an invoking and held UE with the following exception: 

- the MSC Server enhanced for ICS shall also apply interworking procedures as specified in 3GPP TS 29.292 [24] 
for Hold and Resume. 

1 2.2.5 Explicit Communication Transfer (ECT) 

Invocation of ECT at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.629 [19] for a transferor 
UE, transferee UE and transfer target UE with the following exceptions: 

the MSC Server enhanced for ICS shall support the transferor role only when the MSC Server enhanced for ICS 
has a consultation communication with the transfer target (consultative transfer). The MSC Server enhanced for 
ICS shall not support the transferor role for blind or assured transfer. 

the MSC Server enhanced for ICS shall also apply interworking procedures as specified in 3GPP TS 29.292 [24] 
for ECT. 

12.2.6 Conferencing 

Invocation of Conferencing at the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.605 [13] for an 
originating UE and destination UE with the following exceptions: 

a Conference Factory URI shall be derived as specified in 3GPP TS 23.003 [4]; 

conference creation by the MSC Server enhanced for ICS shall be as described in 3GPP TS 24.605 [13] 
subclause 5.3.1.3.3; 

the MSC Server enhanced for ICS shall invite other users to the conference using one of the REFER method 
procedures as specified in 3GPP TS 24.147 [8] subclause 5.3.1.5.2 and subclause 5.3.1.5.3; 

the MSC Server enhanced for ICS shall not subscribe to the conference event package; 

the MSC Server enhanced for ICS shall also apply the interworking procedures as specified in 
3GPP TS 29.292 [24] for Conferencing. 
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12.2.7 Communication Waiting (CW) 



Editor" s note: the conditions under which to respond with a 415 (Unsupported Media Type) final response for the 
purposes of indicating that the MSC Server enhanced for ICS does not support network based CW, are 
FFS. 

Invocation of Communication Waiting at the MSC Server enhanced for ICS shall be as described in 
3GPP TS 24.615 [18] with the following exception: 

the MSC Server enhanced for ICS shall also apply interworking procedures as specified in 3GPP TS 29.292 [24] 
for Commurucation Waiting. 

12.3 Supplementary service invocation for non ICS UE when 
attached to an MSC Server not enhanced for ICS 

12.3.1 Line ID Services (OIP, OIR, TIP, TIR) 

The service control for the Line ID services may be provided by the CS domain if they are provisioned in the CS 
domain. 

12.3.2 Communication Diversion services 

12.3.2.1 Communication Diversion services; CFU, CFNL 

The procedures as defined in 3GPP TS 24.604 [12] apply with the addition of the SCC AS presenting the SIP UA 
behaviour toward IM CN subsystem on behalf of the non ICS UE. 

12.3.2.2 Communication Diversion services; CFNR, CFB 

The procedures as defined in 3GPP TS 24.604 [12] apply with the addition of the SCC AS presenting the SIP UA 
behaviour toward IM CN subsystem on behalf of the non ICS UE. 

12.3.2.3 Communication Diversion services; Communication Deflection 

The service control for the Call Deflection service may be provided by the CS domain if it is provisioned in the CS 
domain. 

12.3.3 Communication Barring 

The procedures as defined in 3GPP TS 24.61 1 [17] apply with the addition of the SCC AS presenting the SIP UA 
behaviour toward IM CN subsystem on behalf of the non ICS UE. 

12.3.4 Communication Hold/Resume 

The service control for the Call Hold and Retrieve services may be provided by the CS domain if they are provisioned 
in the CS domain. 



1 2.3.5 Explicit Communication Transfer 



The service control for the Explicit Call Transfer services may be provided by the CS domain if they are provisioned in 
the CS domain. 



12.3.6 Conferencing 



The service control for the Call Hold and Retrieve services may be provided by the CS domain if they are provisioned 
in the CS domain. 
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1 2.3.7 User configuration of supplementary services 

There are no special procedures for user configuration of supplementary services. 

1 3 Supplementary service configuration for ICS 

13.1 General 

For ICS, the multimedia telephony application server supports the following methods for supplementary service 
configuration: 

Supplementary service setting requests directly from the ICS UE as described in subclause 13.2; or 

Supplementary service setting requests from the MSC Server enhanced for ICS as described in subclause 13.3. 

The multimedia telephony application server shall allow only one method per ICS user. The multimedia telephony 
application server shall reject supplementary service configuration requests if the ICS user has chosen the not allowed 
method. 

13.2 ICSUE 

The procedures as defined in 3GPP TS 24.173 [9] apply for the ICS UE. 

1 3.3 MSC server enhanced for ICS 

The procedures as defined in 3GPP TS 29.292 [24] apply for the MSC Server enhanced for ICS. 
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Annex A (informative): 
Example signalling flows 

A.1 Scope of signalling flows 

This annex includes signalling flows for ICS which provide examples of ICS specific behaviour. Therefore, signalling 
flows that would otherwise be identical to examples of normal behaviour without ICS are not included in this annex. 

In many cases, the signalling flows in this annex expand on the overview information flows provided in 
3GPPTS 23.292 [6]. 



A.2 Introduction 
A.2.1 General 

The signalling flows provided in this annex follow the methodology developed in 3GPP TS 24.228 [10]. The following 
additional considerations apply: 

a) 3GPP TS 24.228 [10] shows separate signalling flows with no configuration hiding between networks, and with 
configuration hiding between networks. There is no ICS specific functionality associated with hiding, and 
therefore such separate signalling flows are not show in the present document; 

b) 3GPP TS 24.228 [10] does not show the functionaUty between the S-CSCF and the AS. As ICS can depend on 
the functionality provided by SCC AS, the signalling flows between S-CSCF and SCC AS are shown in the 
present document; 

c) 3GPP TS 24.228 [10] breaks down the functionality of the various CSCFs. In the present document this is only 
shown for registration. For all other flows the CSCFs are collapsed into a single entity labelled "Intermediate IM 
CN subsystem entities"; 

NOTE: 3GPP TS 24.228 [10] is an informative specification that is no longer maintained and cannot be used for 
specifying ICS requirements. It is not intended that the reader refer to 3GPP TS 24.228 [10] beyond the 
subclause on methodology. 

d) where entities are combined as in c) above, and the signalling flow is directed to such a combined entity, the 
contents of the signalling flow represent the contents of the sending entity; and 

e) where entities are combined as in c) above and the signalling flow originates at such a combined entity, the 
contents of the signalling flow represent the contents of the receiving entity; and 

f) ordering of headers within a table does not follow the conventions of 3GPP TS 24.228 [10]. 

A.2. 2 Key required to interpret signalling flows 

The key to interpret signalling flows specified in 3GPP TS 24.228 [10] subclauses 4.1 and 4.2 applies with the additions 
specified below: 

sip:234150999999999@ics. mnc015.mcc234.3gppnetwork.org represents the temporary public user ID used for 
registration. 

sip:sccas. homel.net represents the address of the SCC AS on the originating side. 

sip:sccas2. home2.net represents the address of the SCC AS on the terminating side. 

Each signalling flow table contains descriptions for headers where the content of the header is new to that signalling 
flow, as is already performed in 3GPP TS 24.228 [10]. 
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However, 3GPP TS 24.228 [10] includes extensive descriptions for the contents of various headers following each of 
the tables representing the contents of the signalling flows. Where the operation of the header is identical to that shown 
in 3GPP TS 24.228 [10], then such text is not reproduced in the present document. 

Additional text can also be found on the contents of headers within 3GPP TS 24.228 [10] in addition to the material 
shown in the present document. 

In order to differentiate between messages for SIP and media, the notation in figure A. 2-1 is used. 



INVITE 



SETUP 



SIP message 

CS message, NAS message 
Media over a PS connection 

Media over a CS connection 



Figure A.2-1 : Signalling flow notation 



A.3 Signalling flows for registration 

A.3.1 Signalling flows for CS UE IMS registration when using an 
MSC Server enhanced for ICS 

Figure A.3. 1-1 shows the registration in the IM CN subsystem performed by the MSC Server enhanced for ICS, on 
behalf of a UE. The registration is triggered upon a CS attach of the UE. In this example the MSC Server is enhanced 
for ICS and is capable of translating NAS signalling received from the UE to SIP and vice versa. In this example an 
IBCF is not used. 
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UEA 



MSC Server/VLR 



HSS/HLR 



l-CSCF 



S-CSCF 



sec AS 



-1.CSATTACI+*. 



3. CS ATTACH 
ACCEPT 




4. IMS 
Registration 
Evaiuation 



5. IMS address 
discovery 



-6. SIP REGISTER- 




10. SIP200(OK)_ 



11.SIP200(OK)_ 



12. IPC 
evaluation 



-13. SIPREGISTER^ 

14. SIP 200 (OK) 



-16. SIPSUBSCRIBE- 
17. SIP200(OK)_ 



15. AS can 
subscribe to 
Reg-Event 



-18. SIPN0TIFY- 



-19. SIP200(OK)- 



Figure A.3.1-1 MSC Server enhanced for ICS performs registraton on behalf of the UE 

The details of the signalling flows are as follows: 

1. CS attach (UE A to MSC) 

As a result of some stimulus, UE A performs CS attachment procedure as specified in 3GPP TS 24.008 [7]. 

2. Authentication and Update Location (MSC/VLR to HLR/HSS) 

MSCA'^LR retrieves authentication vectors for the received IMSI as specified in 3GPP TS 29.002 [20] and 
challenges UE A as specified in 3GPP TS 24.008 [7]. After successful authentication, the MSC/VLR sends 
update location to the HSS/HLR as specified in 3GPP TS 29.002 [20]. HSS/HLR returns subscriber data for the 
IMSI that was sent by the MSC/VLR. 



3. CS attach accept (MSC to UE A) 
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The CS attach request is accepted by the network, an accept message is sent to the MS. 

4. IMS Registration evaluation 

The MSC Server enhanced for ICS evaluates whether it needs to perform registration with the IM CN 
subsystem. This can be based on subscriber data received from the HSS/HLR. 

5. IMS address discovery 

The MSC Server enhanced for ICS derives a home network domain name as described in 3GPP TS 23.003 [4]. 
The home network domain is used to perform DNS queries to locate the I-CSCF in the home network. 

6. REGISTER request (MSC Server enhanced for ICS to I-CSCF) - see example in table A.3.1-6 

The purpose of this request is to register a private user identity and a temporary public user identity derived from 
the subscriber"s IMSI on behalf of the user with an S-CSCF in the home network. This request is routed to the I- 
CSCF in the home network. In this example no IBCF is employed. 

Table A.3.1-6: REGISTER request (MSC Server enhanced for ICS to I-CSCF) 



REGISTER sip: ics.mnc015.mcc234.3gppnetwork.org SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

P-Visited-Network-ID : "Visited Network Number 1 for MSC Server" 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 

From: <sip:234150 999999999®ics .mnc015 .mcc2 34 . 3gppnetwork . org> ; tag=4f a3 

To: <sip:234150 999999999@ics .mnc015 .mcc234 . 3gppnetwork . org> 

Contact : <sip:[5555:: aaa :bbb: ccc :ddd] > ; expires=600000 ;+sip . instance=" <urn : gsma : imei : 90420156- 

025763 - 0> "; +g. 3gpp. icsi-ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" ; +g. 3gpp. ics=" server" 
Call -ID: apb03aOs0 9dkjdfglkj4 9111 
Authorization: Digest username=" 234150999999999Oics.mnc015.mcc234.3gppnetwork.org ", realm=" 

ics.mnc015.mcc234.3gppnetwork.org ", nonce="", integrity-protected="auth-done" , uri="sip: 

ics.mnc015.mcc234.3gppnetwork.org ", response="" 
CSeq: 1 REGISTER 
Supported: path, gruu 
Content-Length: 



R-URI: Contains the home network domain name that was derived from the subscribers IMSI as described in 
3GPP TS 23.003 [4]. In the given example, the IMSI of the subscriber is 234150999999999. 

From: the temporary public user identity that was derived form the subscribers IMSI as described in 
3GPP TS 23.003 [4]. In the given example, the IMSI of the subscriber is 234150999999999. 

To: the temporary public user identity that was derived form the subcribers IMSI as described in 
3GPP TS 23.003 [4]. In the given example, the IMSI of the subscriber is 234150999999999. 

Contact: The point-of-presence representing UE A, i.e. an IP address at the MSC Server enhanced for ICS 

allocated for UE a. The Contact header field contains an instance ID and a feature tag indicating that the MSC 
Server is acting as an MSC Server enhanced for ICS services. 

7. Cx: User registration status query procedure 

The I-CSCF employs network domain security mechanisms to ensure that the REGISTER request was received 
from a trusted node. The I-CSCF makes a request for information related to the Subscriber registration status by 
sending the private user identity, public user identity and visited domain name to the HSS as specified in see 
3GPP TS 29.228 [23]. The HSS returns the S-CSCF required capabilities and the I-CSCF uses this information 
to select a suitable S-CSCF. 

8. REGISTER request (I-CSCF to S-CSCF) - see example in table A.3.1-8 

I-CSCF forwards the REGISTER request to the selected S-CSCF. 
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Table A.3.1-8: REGISTER request (l-CSCF server to S-CSCF) 



REGISTER sip: ics .mncOlB .mcc234 . 3gppnetwork.org SIP/2.0 

Via: SIP/2. 0/UDP icscf .homel.net;branch=z9hG4bK240f34 .1, SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] 

Max-Forwards: 69 

P-Access-Network-Info : 

P-Visited-Network-ID : 

P-Charging-Vector : 

From: 

To: 

Contact : 

Call-ID: 

Authorization : 

CSeq: 

Supported: 

Content-Length : 



9. Cx: S-CSCF Registration Notification 

Based on configuration data, the S-CSCF knows that the subscriber has already been authenticated by the MSC 
Server enhanced for ICS. The S-CSCF informs the HSS that the user has been registered. Upon being requested 
by the S-CSCF, the HSS will also include the user profile in the response sent to the S-CSCF. For detailed 
message flows see 3GPP TS 29.228 [23]. 

10. 200 (OK) response (S-CSCF to I-CSCF) - see example in table A.3.1-10 

The S-CSCF sends a 200 (OK) response to the I-CSCF indicating that Registration was successful. 

Table A.3.1-10: 200 (OK) response (S-CSCF to I-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 1 . homel . net ;branch=z9hG4bK351g45 . 1 , SIP/2. 0/UDP 
[5555: : aaa: bbb: CCC: ddd] :1357; branch=z9hG4bKnashds7 

Path: <sip : term@msc . visitedl .net; lr> 

Service-Route : <sip : origOscscf 1 . homel . net ; lr> 

From: 

To: 

Call-ID: 

Contact: <sip: [5555 :: aaa :bbb : ccc :ddd] >; pub-gruu="sip : 

user2_publicl@homel .net ;gr=urn:uuid: f81d4fae-7dec-lld0-a765-00a0c91eSbfS"; temp- 
gruu="sip: tgruu. 7hs==jd7vnzga5w7f ajsc7- 
ajd6f abzOf 8g5@example . com;gr" ; +sip. instance="<urn:uuid: f81d4fae-7dec-lldO-a7G5- 
00a0c91e6bf 6>" ; +g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics= "server; expires=GOOOOO 

CSeq: 

P-Associated-URI : <user2_publicl®homel .net>, <tel : +358504821437> 

Content-Length : 



11. 200 (OK) response (I-CSCF to MSC Server enhanced for ICS) - see example in table A.3.1-11 

The I-CSCF forwards the 200 (OK) response to the MSC Server enhanced for ICS indicating that Registration 

was successful. 

Table A.3.1-11 : 200 (OK) response (I-CSCF to MSC Server enhanced for ICS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa :bbb : ccc : ddd] : 1357 ; branch=z9hG4bKnashds7 

Path: 

Service-Route : 

From: 

To: 

Call-ID: 

Contact : 

CSeq: 

P-Associated-URI : 

Content-Length : 



12. iFC evaluation 
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Select the filter criteria for originating session case and check the REGISTER request for the temporary public 
user identity against the initial filter criterion with the highest priority. In this example there is a match for the 
sec AS and therefore the S-CSCF will send a third party REGISTER request to the SCC AS. In this example 
the filter criteria contains an Include Register Request XML element and an Include Register Response XML 
element. 

13. REGISTER request (S-CSCF to SCC AS) - see example in table A.3.1-13 

The S-CSCF sends a third party REGISTER request containing in the body the incoming REGISTER request 
from the PN UE and the 200 (OK) response to the incoming REGISTER request to the SCC- AS. 

Table A.3.1-13: REGISTER request (S-CSCF to SCC AS) 



REGISTER sip: scc_as .homel .net SIP/2.0 

Via: SIP/2. 0/UDP scscfl . homel . net ;branch=z9hG4bK240f 34 . 1 , SIP/2 . 0/UDP [5555 : : aaa :bbb : ccc : ddd] 

Max-Forwards: 70 

From: <sip: scscfl .homel .net>; tag=2123 5 

To: <sip :user2_publicl®homel .net> 

Contact: <sip: scscfl .homel .net> 

Call-ID: 

Expires: 600000 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

P-Charging-Function-Address : ccf =192 . 1 . 1 . 1; ecf =192 . 1 . 1 . 2 

CSeq: 

Content - Type : mul t ipart /mixed ; boundary= " boundaryl " 

Content-Length: (...) 

--boundaryl 

Content-Type: message/sip 

REGISTER sip: ics .mnc015 .mcc234 . 3gppnetwork.org SIP/2.0 

Via: SIP/2. 0/UDP icscf. homel. net;branch=z9hG4bK240f 34 .1, SIP/2. 0/UDP [5555 :: aaa :bbb : ccc : ddd] 

Max-Forwards: 69 

P-Visited-Network-ID: "Visited Network Number 1 for MSC Server" 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 

From: <sip:234150999999999®ics .mnc015 .mcc234 . 3gppnetwork . org> ; tag=4f a3 

To: <sip: 234 150 9999 99999@ics .mnc015 .mcc234 . 3gppnetwork . org> 

Contact : <sip:[5555:: aaa :bbb : ccc : ddd] > ; expires=600000 ;+sip. instance=" <urn : gsma : imei : 90420156- 

025763 - 0> "; +g. 3gpp. icsi-ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" ; +g. 3gpp. ics=" server" 
Call -ID: apb03aOs0 9dkjdfglkj4 9111 
Authorization: Digest username="234150999999999®ics .mnc015 .mcc234 . 3gppnetwork.org ", realm=" 

ics.mnc015.mcc234.3gppnetwork.org ", nonce="", integrity-protected="auth-done" , uri="sip: 

ics.mnc015.mcc234.3gppnetwork.org ", response="" 
CSeq: 1 REGISTER 
Supported: path, gruu 
Content-Length: 

--boundaryl 

Content-Type: message/sip 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 1 . homel . net ;branch=z9hG4bK351g45 . 1 , SIP/2. 0/UDP 
[5555: : aaa: bbb: ccc: ddd] :1357; branch=z9hG4bKnashds7 

Path: <sip : termOmsc . visitedl .net; lr> 

Service-Route : <sip : origOscscf 1 . homel . net ; lr> 

From: <sip:23415 999999999@ics .mnc015 .mcc234 . 3gppnetwork . org> ; tag=4f a3 

To: <sip:234150 999999999®ics .mnc015 .mcc234 . 3gppnetwork . org> 

Call -ID: apb0 3a0s0 9dkjdfglkj4 9111 

Contact: <sip: [5555 :: aaa :bbb : ccc :ddd] >; pub-gruu="sip : 

user2_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a7 65-0 0a0c91e6bf 6" ; temp- 
gruu="sip: tgruu. 7hs==jd7vnzga5w7f ajsc7- 
ajd6f abzOf 8g5(aexample . com;gr" ; +sip. instance="<urn:uuid: f81d4fae-7dec-lld0-a765- 
00a0c91e6bf 6>" ; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- 
service . ims .icsi .mmtel" ; +g. 3gpp. ics=" server" ;expires=600000 

CSeq: 1 REGISTER 

P-Associated-URI : <user2_publicl®homel .net>, <tel : +358504821437> 

Content-Length: 

--boundaryl-- 



14. 200 (OK) response (SCC AS to S-CSCF) 

The SCC- AS sends a 200 (OK) response to the S-CSCF indicating the third party REGISTER was successful. 
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15. sec AS can subscribe to reg-event 

The sec AS can subscribe to the reg event package for the public user identity registered at the S-CSCF. 
Contents of the flows for subscription to reg-event from the SCC-AS to the S-CSCF are similar as shown in 
messages 15) to 20). 

16. SUBSCRIBE request (MSC Server enhanced for ICS to S-CSCF) - see example in table A.3.1-16 

The MSC Server enhanced for ICS subscribes to the reg-event package. 

Table A.3.1-16: SUBSCRIBE request (MSC Server enhanced to l-CSCF) 



SUBSCRIBE sip:user2_publicl@homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Asserted- Identity : <sip :userl_publicl@homel .net> 

Privacy: none 

From: <sip :user2_publicl@homel .net>; tag=31415 

To : <sip : user2_publicl@homel . net> 

Route : <sip : origOscscf 1 . homel . net ; lr> 

Call-ID: dre36d2v32gnlgiiomm72445 

CSeq: SI SUBSCRIBE 

Event : reg 

Expires: 6 00 00 

Accept: application/reginfo+xml 

Contact : 

Content-Length: 



17. 200 (OK) response (S-CSCF to MSC Server enhanced for ICS) - see example in table A.3.1-17 

The S-CSCF sends a 200 (OK) response to the MSC Server enhanced for ICS indicating that the subscription is 
established. 

Table A.3.1-17: 200 (OK) response (S-CSCF to MSC Server enhanced for ICS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa : bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Max- Forwards : 70 

P-Asserted- Identity : <sip:scscfl .homel .net> 

Privacy: 

From: 

To : <sip : user2_publicl@homel . net> ; tag=151170 

Call-ID: 

CSeq: 

Contact: <sip : scscfl .homel .net> 

Expires : 

Content-Length : 



18. NOTIFY request (S-CSCF to MSC Server enhanced for ICS) - see example in table A.3.1-18 

The S-CSCF sends a first NOTIFY request towards the MSC Server enhanced for ICS in order to inform about 
the registration status of the monitored user. 
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Table A.3.1-18: NOTIFY request (S-CSCF to MSC Server enhanced for ICS) 



NOTIFY sip: [5555 : :aaa:bbb:ccc :ddd] : 1357; comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1 

Max- Forwards : 70 

From: <sip :user2_publicl@homel .net>; tag=31415 

To : <sip : user2_publicl@homel . net> ; tag=151170 

Call-ID: 

CSeq: 42 NOTIFY 

Subscript ion- St ate : active; expires=600000 

Event : reg 

Content-Type : application/reginf o+xml 

Contact: <sip : scscf 1 .homel .net> 

P- Charging- Info : icid=ee36d84688f e;orig-ioi=homel .net 

Content-Length: (...) 

<?xml version="l . 0"?> 

<reginfo xmlns="urn: ietf :params :xml :ns : reginfo" 

xmlns :gr="urn: ietf :params :xml :ns :gruuinfo" 
version="l" state="full"> 
<registration aor="sip :user2_publicl@homel .net" id="a6" state="active" > 
<contact id="75" state="active" event= " created" > 
<uri>sip : [5555 : : aaa :bbb : ccc :ddd] </uri> 
<allOneLine> 

<unknown-param name="+sip . instance" > 
"&;lt;urn: gsma: imei : 90420156 - 025763 -O> " 
</unknown-param> 

<unknown-param name= ' +g. 3gpp . icsi-ref ' >S;lt ;urn:urn-7 : 3gpp- 
service . ims . icsi .mmtel&gt ; ' </unknown-param> 

<unknown-param name= ' +g. 3gpp . ics ' >&;lt ; server&gt ; ' </unknown-param> 
</allOneLine> 
<allOneLine> 

<gr :pub-gruu uri="sip :user2_publicl@homel .net 
;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6"/> 
</allOneLine> 
<allOneLine> 

<gr : temp-gruu uri="sip : tgruu. 7hs = = jd7vnzga5w7f aj sc7-ajd6f abzOf 8g5®homel .net 
;gr" f irst-cseq="54301"/> 
</allOneLine> 

</contact> 
</registration> 

<registration aor="tel : +358504821437" id="a7" state="active" > 
<contact id="77" state="active" event="created" > 
<uri>sip : [5555 : : aaa:bbb:ccc :ddd] </uri> 

</contact> 
</registration> 
</reginfo> 



The message body in the NOTIFY request that carries the subscriber's registration state is formed as indicated in 
3GPPTS 24.229 [11]. 

19. 200 (OK) response (MSC Server enhanced for ICS to S-CSCF) - see example in table A.3.1-19 
Table A.3.1-19: 200 (OK) response (MSC Server enhanced for ICS to S-CSCF) 



SIP/2.0 200 OK 
Via: SIP/2. 0/UDP 


[5555 


: aaa 


bbb 


ccc :ddd] 


;branch=z 


9hG4bKnashds7 


P-Acces£ 


-Network- 


Info: 


3GPP 


-UTRAN 


-TDD; utran- 


cell 


-id- 


3gpp= 


=234151D0FCE11 


From: 
























To: 
























Call-ID 
























CSeq: 

Content - 


Length: 
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A.4 Signalling flows for call origination 

A.4.1 Signalling flows for ICS UE origination with CS media using 
Gm reference point when using an MSC Server enhanced 
for ICS 

Figure A.4. 1-1 shows the origination of a call from an ICS UE using CS bearers controlled through the IM CN 
subsystem. In this example the MSC Server is enhanced for ICS and is capable of translating NAS signalling received 
from the ICS UE to SIP and vice versa. If the MSC is not enhanced for ICS, translation of NAS signalling to ISUP is 
required before routing towards a MGCF for interworking with the IM CN subsystem, as shown in subclause A.4. 2. 
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Figure A.4.1-1 : ICS UE Origination withi CS media using Gm reference point whien using an IVISC 

Server enhianced for ICS 

The details of the signalling flows are as follows: 

1 . Determination of call establishment 

As a result of some stimulus to establish a session with voice media, the ICS UE based on a combination of user 
policy, and access technology availability, decides to establish the service control signalling using the IM CN 
subsystem. 

The ICS UE initiates service control signalling in the IM CN subsystem towards the SCC AS by sending a SIP 
INVITE request to the intermediate IM CN subsystem entities. 

2. SIP INVITE request (ICS UE to intermediate IM CN subsystem entities) - see example in table A.4.1-2. 

Table A.4.1-2: SIP INVITE request (ICS UE to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 .homel .net : 75 31; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net; lr> 

P -Preferred- Identity : <sip :user2_publicl®homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :user2_publicl®homel .net>; tag=17182 8 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu 

Accept : application/sdp, application/3gpp-ims+xml 

Require: sec-agree 

Proxy-Require: sec-agree 

Accept -Contact : * ; +g. 3gpp . icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

P- Preferred- Service : urn: urn- 7 : 3gpp- service. ims .icsi .mmtel 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; port=7531 

Contact : <sip :user2_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6; 

; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" ; +g. 3gpp. ics= "principal" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s = 

c=PSTN - - 

t = 

m=audio 9 PSTN - 

a=setup : active 

a=connection : new 

a=curr: qos local none 

a=curr: qos remote none 

a=des: qos mandatory local sendrcv 

a=des: qos mandatory remote sendrcv 

a=inactive 



Request-URI: the SIP URI or tel URI of the called party. In this example the tel URI of the called party is 
included in the tel URI. 

The SDP included in this SIP INVITE request indicates that the session is to be setup using CS bearers as 
described in draft-ietf-mmusic-sdp-cs [36]. 

3. SIP 100 (Trying) response (intermediate IM CN subsystem entities to ICS UE) 

The intermediate IM CN subsystem entities respond to the ICS UE with a SIP 100 (Trying) response 
There is no ICS specific content in this response. 

4. Evaluation of initial filter criteria 
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The S-CSCF evaluates initial filter criteria for the served ICS user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) - see example in table A.4.1-5. 
Table A.4.1-5: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK24 0f34 .1, SIP/2 .0/UDP 
[5555 : :aaa:bbb: ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 68 
Route : <sip : sccas .homel .net; lr>, <sip : Cb03a0s0 9a2sdfglkj4 90 3 3 3@scscf 1 .homel .net; lr>;orig- 

dialog-id="0: 73 935718_92645110 -712786 jd2463 953 02d-zKE" 
Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .homel .net ; lr> 
P- Asserted- Identity: <sip :user2_publicl@homel .net>,<tel:+358-50-4821437> 
P-Access-Network-Info : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Accept : 
Require : 
Proxy-Require : 
Accept-Contact : 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims . icsi .mmtel 
Security-Verify: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v=0 

o= 

s = 

c= 

t= 

m= 



6. SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 
There is no ICS specific content in this response. 

7. SCC AS allocates an lUA PSI DN to the ICS UE 

The SCC AS stores the information received in the initial INVITE request and associates an lUA PSI DN with 
this request. The lUA PSI DN is returned in a SIP to the ICS UE together with an inidcation that CS bearer 
establishment is to be initiated by the ICS UE. For this example the lUA PSI DN is chosen as +1212556666. 

8. SIP 183 (Session Progress) response (SCC AS to intermediate IM CN subsystem entities) - see example in 
table A.4.1-8 
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Table A.4.1-8: SIP 183 (Session Progress) response (SCC AS to intermediate IM CN subsystem 

entities) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 
pcscf 1 . visitedl .net ;branch=z9hG4bK24 0f 34 .1, SIP/2 . 0/UDP 
[5555 : :aaa:bbb: ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip:scscfl .homel .net; lr>, <sip : pcscf 1 .visitedl .net; lr> 

P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <tel : +1-212 -555- 1111> ; tag=171828 

To : <sip : user2_publicl®homel . net> 

Call-ID: 

CSeq: 

Require: lOOrel, precondition 

Contact : <sip : sccas . homel . net> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933622 2987933622 IN IP6 5555 : : eee : f f f : aaa :bbb 

s = - 

C=PSTN E164 +12125556666 

t = 

m=audio - PSTN - 

a=setup :passive 

a=connection : new 

a=curr: qos local none 

a=curr: qos remote none 

a=des : qos mandatory sendrcv 

a=des : qos mandatory sendrcv 

a=inactive 



The lUA PSI DN is returned in the SDP body using the mechanisms described in draft-ietf-mmusic-sdp-cs [36]. 

9. SIP 183 (Session Progress) response (intermediate IM CN subsystem entities to ICS UE) 

The SIP 183 (Session Progress) response is routed towards the ICS UE from the intermediate IM CN subsystem 
entities. 

10. SIP PRACK request and SIP 200 (OK) response 

The ICS UE sends a SIP PRACK request towards the SCC AS via the intermediate IM CN subsystem entities as 
a result of receiving the reliably sent SIP 183 (Session Progress) response containing the SDP answer. 

Upon receipt of the SIP PRACK request, the SCC AS responds with a SIP 200 (OK) response towards the ICS 
UE via the intermediate IM CN subsystem entities. 

The is no ICS specific content in these SIP messages. 

NOTE: In the event that the SCC AS does not receive a PRACK request, the SCC AS is capable of handling a 

new SIP INVITE request sent from the ICS UE as per normal SIP procedures. In this case a new lUA PSI 
DN would be returned to the ICS UE in the SIP 183 (Session Progress) response. 

1 1 . ICS UE proceeds to setup CS bearers 

Upon receipt of the lUA PSI DN, the ICS UE proceeds with setting up the call using CS bearers. 

12. SETUP message (ICS UE to MSC Server enhanced for ICS) 

The ICS UE initiates the call over CS bearers by sending a SETUP message to the MSC Server enhanced for 
ICS. 

Specifically for this signalling flow, the SETUP message includes: 

Called Party Number information element = [(Numbering plan identifier = ISDN/telephony numbering plan), 
(type of number = international number ), (Number digits = 1212556666)] . The Called Party Number 
information element is set to the lUA PSI DN. 



£75/ 



3GPP TS 24.292 version 8.4.0 Release 8 57 ETSI TS 1 24 292 V8.4.0 (201 0-01 ) 

Bearer Capability information element = [(information transfer capability = speech), (speech versions = FR 
AMR, GSM EFR, GSM PR)] 

- Supported Codec List information element = { [(SysID 1 = UMTS), (Codec Bitmap for SysID 1 = UMTS 
AMR 2)], [(SysID 2 = GSM), (Codec Bitmap for SysID 2 = FR AMR, GSM EFR, GSM FR)] } 

The MSC Server enhanced for ICS knows the calling party number corresponding to the UE. 

13. CALL PROCEEDING message (MSC Server enhanced for ICS to ICS UE) 

Upon receipt of the SETUP message from the ICS UE, the MSC Server enhanced for ICSresponds with a CALL 
PROCEEDING message. There is no ICS specific content in this message. 

14. SIP INVITE request (MSC Server enhanced for ICS to intermediate IM CN subsystem entities) - see 
example in table A.4.1-14 

The MSC Server enhanced for ICS maps the received SETUP message to a SIP INVITE request which is 
addressed to the lUA PSI DN. 

Table A.4.1-14: SIP INVITE request (MSC Server enhanced for ICS to intermediate IM CN subsystem 

entities) 



INVITE tel:+l-212-555-6666 SIP/2.0 

Via: SIP/2. 0/UDP mscl .homl .net;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route: <sip : icscf 1 .homel .net : lr> 

P- Asserted- Identity: <sip :user2_publicl@homel .net>, <tel:+358-50-4821437> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

P-Access-Network-Inf o : 

Privacy: none 

From: <sip :user2_publicl@homel .net>; tag=17182 8 

To: <tel:+l-212-555-6666> 

Call -ID: f81d4fae-7dec-lld0-a765-0 0a0c91e6bf6 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, 199 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip :user2_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6>; 

+g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" ; +g. 3gpp. ics=" server" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s- 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



Request-URI: UAI PSI DN as received in the SETUP message 

P-Asserted-Identity: The MSC Server enhanced for ICS inserts the tel-URI containing the subscriber number, as 
received from the ICS UE 

Accept-Contact: The MSC Server enhanced for ICS includes the mmtel feature tag in the INVITE request . 

Contact: The MSC Server enhanced for ICS includes the GRUU received at registration, the feature tag 

g.3gpp. icsi-ref set to "urn%3Aurn-7%3gpp-service. ims. icsi. mmtel" and the feature tag g.3gpp.ics set to "server". 

SDP: The SDP contains preconfigured set of codecs supported by the MGW. 
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15. SIP 100 (Trying) response (intermediate IM CN subsystem entities to enahanced MSC Server) 

The intermediate IM CN subsystem entities respond to the MSC Server enhanced for ICS with a SIP 100 
(Trying) response. 

There is no ICS specific content in this response. 

16. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) - see example in table A.4.1-16 

The SIP INVITE request is routed towards the SCC AS. 

Table A.4.1-16: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 



INVITE tel:+l-212-555-6666 SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

icscf 1 .homel .net ;branch=z9hG4bKdwe534 , SIP/2 . 0/UDP mscl .homl .net ;branch=z9hG4bKnashds7 
Max- Forwards : 68 
Route : <sip : sccasl .homel .net :lr>, <sip:scscfl .homel .net; lr>;orig-dialog- 

id="yuf lsae80r3rb3fh31ondyr82 9cnyr3 81cn93 2YDWref 0w0-wwtg3 74" 
Record-Route : <sip : scscf 1 . homel . net : lr> 

P- Asserted- Identity: <sip :user2_publicl®homel .net>,<tel:+358-50-4821437> 
P- Charging- Function-Addresses : ccf = [5555 : :b99 : c8 8 :d77 : e6 6] ; ccf = [5555 : : a55 :b44 : c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi="type 

3 homel .net" ; or ig-ioi=" homel .net" 
P-Access-Network-Info : 
Privacy: none 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Accept-Contact : 
P-Asserted-Service : 
Contact: Allow: 
Content-Type : 
Content-Length : 



17. SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 
There is no ICS specific content in this response. 

18. SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.4.1-18 

The SCC AS acting as a routing B2BUA, generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE B via the 
intermediate IM CN subsystem entities. 
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Table A.4.1-18: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP sccasl .homel .net;branch=z9hG4bKnas34r5 

Max-Forwards: 67 

Route: <sip : scscfl .homel .net : lr> 

Record-Route : <sip : scscfl . homel . net ; lr> 

P- Asserted- Identity: <sip :user2_publicl@homel .net>, <tel:+358-50-4821437> 

P- Charging- Function-Addresses : ccf = [5555 : :b99 : c88 :d77 : e66] ; ccf = [5555 : : a55 : b44 : c33 : d22] ; 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : See : 9dd] 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig- 

ioi="type3homel .net" 
P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id=3gpp=234151D0FCEll 
Privacy: none 

From: <sip :user2_publicl@homel .net>; tag=274890 
To: <tel:+l-212-555-2222> 

Call -ID: f81d4fae-7dec-lldO-a765-OOaOc91e6bf6 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, 199 
Require: sec-agree 
Proxy-Require: sec-agree 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; port=7531 
Contact : <sip :user2_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-0 0a0c91e6bf 6> 

; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



Request-URI: The SCC AS replaces the lUA PSI DN with the tel URI of the called party which was stored 
from the initial SIP INVITE request sent in step 2. 

Contact: In this example the SCC AS includes the contents of the Contact header from the received SIP 
INVITE request except the g.3gpp.ics media feature tag which is removed by the SCC AS. 

19. SIP 100 (Trying) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities respond to the SCC AS with a SIP 100 (Trying) response. 
There is no ICS specific content in this response. 

20. SIP INVITE request (intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities route the SIP INVITE request to UE B. 

21. SIP 100 (Trying) response (UE B to intermediate IM CN subsystem entities) 

UE B responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 

There is no ICS specific content in this response. 

22-23. SIP 180 (Ringing) response (UE B to SCC AS via intermediate IM CN subsystem entities) 

UE B responds to the received SIP INVITE request with a SIP 180 (Ringing) response. The response contains no 
SDP body and contains no ICS specific content. 
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24-25. SIP 180 (Ringing) response (SCC AS to ICS UE A via intermediate IM CN subsystem entities) 

Upon receiving the SIP 180 (Ringing) response from the terminating UE, the SCC AS sends a SIP 180 (Ringing) 
response to the ICS UE A via the intermediate IM CN subsystem entities. The response is associated with the 
SIP INVITE in step 2 and contains no ICS specific content. In this example the SCC AS includes in the Contact 
header field the contents of the Contact header field received in the SIP 180 (Ringing) response from the 
terminating side. Furthermore, the SIP 180 (Ringing) contains no SDP body. 

26. SIP 200 (OK) response (UE B to to intermediate IM CN subsystem entities) - see example in table A.4.1- 
26 

The terminating side sends an SDP answer in a SIP 200 (OK) response to the received SIP INVITE request. 
Table A.4.1-26: SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2 . 0/UDP pcscf2 .visited2 .net : 5088 ;comp=sigcomp;branch=z9hG4bK361k21 . 1, 

scscf 2 .homel .net ;branch=z9hG4bK764z87 . 1, icscf 1 .homel .net ;branch=z9hG4bK8 71yl2 . 1, 

SIP/2. 0/UDP scscf 1. homel. net , •branch=z9hG4bK332b23 .1, SIP/2. 0/UDP sccasl .homel .net ;branch= 

z9hG4bKnas34r5 
Record- Route : <sip ipcscf 2 . visited2 .net : 5 088 ; lr;comp=sigcomp>, <sip:scscf2 . visited2 .net; lr>, 

<sip:scscfl .homel .net;lr>, <sip:scscfl .homel .net ; lr> 
P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From: <tel: +1-212- 555 -llll>;tag=274890 
To : <sip : user2_publicl@homel . net> ; tag=4f a328 
Call-ID: 
CSeq: 

Require: lOOrel, precondition 
Contact : <sip:user2_publicl®home2 .net ;gr=urn:uuid: 2ad8950e-4 8a5-4a74-8d99-ad76cc7f c74>; 

+g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933623 2987933623 IN IP6 5555 : : ggg : f f f : aaa : bbb 

s = - 

c = IN IP6 5555 : :ggg:fff :aaa:bbb 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrcv 

a=curr:qos remote sendrcv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=maxptime : 20 



27. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The SIP 200 (OK) response from UE is routed towards the SCC AS. 

28-29. SIP 200 (OK) response (SCC AS to MSC Server enhanced for ICS via intermediate IM CN subsystem 
entities) 

The SDP answer received in the SIP 200 (OK) response is routed to the MSC Server enhanced for ICS via the 
intermediate IM CN subsystem entities. In this example the SCC AS includes in the Contact header field the 
contents of the Contact header field received in the SIP 200 (OK) response from the terminating side. 

30. CONNECT message (MSC Server enhanced for ICS to ICS UE) 

The MSC Server enhanced for ICS maps the received SIP 200 (OK) response to a CONNECT message. There is 
no ICS specific content in this message. 

31. CONNECT ACKNOWLEDGMENT (ICS UE A to MSC Server enhanced for ICS) 

The ICS UE A sends a CONNECT ACKNOWLEDGMENT message upon receiving the CONNECT message. 
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32-33. SIP ACK request (MSC Server enhanced for ICS to SCC AS via intermediate IM CN subsystem 
entities) 

Upon receiving the CONNECT ACKNOWLEDGEMENT from the ICS UE A, the MSC Server enhanced for 
ICS forwards a SIP ACK request to the SCC AS via the intermediate IM CN Subsystem entities. 

There is no ICS specific content in this request. 

34-35. SIP 200 (OK) response (SCC AS to ICS UE A via intermediate IM CN subsystem entities) 

The SCC AS responds with a SIP 200 (OK) response to the initial INVITE request sent by the ICS UE A in the 
step 2. Since the SDP answer was previously sent in the SIP 183 (Session Progress) response, the SIP 200 (OK) 
response contains no SDP body. In this example the SCC AS includes in the Contact header field the contents of 
the Contact header field received in the SIP 200 (OK) response from the terminating side. 

36-37. SIP ACK request (ICS UE A to SCC AS via intermediate IM CN subsystem entities) 

The ICS UE A sends a SIP ACK request to the SCC AS via the intermediate IM CN subsystem entities. There is 
no ICS specific content in this response. 

38-39. SIP ACK request (SCC AS to UE B via intermediate IM CN subsystem entities) 

The SCC AS sends a SIP ACK request to UE B via the IM CN subsystem entities. There is no ICS specific 
content in this response. 

A.4.2 Signalling flows for ICS UE origination with CS media using 
Gm reference point when using an MSC Server not 
enhanced for ICS 

Figure A.4.2- 1 shows the origination of a call from an ICS UE using CS bearers controlled through the IM CN 
subsystem. In this example the MSC Server is not enhanced for ICS thus translation at the MGCF of ISUP message to 
SIP messages is required. 
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Figure A.4.2-1 : ICS UE Origination withi CS media using Gm reference point whien using an IVISC 

Server not enhianced for ICS 

The details of the signalling flows are as follows: 

1-13: These steps are identical to steps 1-13 described in subclause A.4.1. 

14. ISUP lAM (MSC Server not enhanced for ICS to MGCF) 

The MSC Server not enhanced for ICS maps the received SETUP message to an ISUP lAM message that is 
routed towards the MGCF. 

Specifically for this signalling flow, the lAM includes: 

Called Party Number parameter = [Numbering plan identifier = ISDN/telephony numbering plan], (type of 
number = international number), (Number digits = 12125556666)]. The Called Party Number is set to the 
UAI PSI DN, as received in the SETUP message. 

Calling Party Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of 
number = international number), (Number digits = 12125551 1 1 1)] 

15. SIP INVITE request (MGCF to intermediate IM CN subsystem entities) - see example in table A.4.2-15 

The MGCF interworks the received lAM message to a SIP INVITE request which is addressed to the lUA PSI 
DN. 

Table A.4.2-15: SIP INVITE request (IVIGCF to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-6666 SIP/2.0 

Via: SIP/2. 0/UDP mgcfl.homl.net;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route: <sip : icscf 1 .homel .net : lr> 

P-Asserted-Identity: <tel: +l-212-555-llll> 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: none 

From: <tel:+358-50-4821437>;tag=171828 

To: <tel:+l-212-555-6666> 

Call -ID: f81d4fae-7dec-lldO-a765-OOaOc91e6bf6 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, 199 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service. ims .icsi .mmtel 

Contact : <sip :mgcf 1 .homel .net>; +g. 3gpp . icsi -ref="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 



Request-URI: UAI PSI DN as received in the SETUP message 

P-Asserted-Identity: The MGCF inserts the tel-URI containing the subscriber number, as received from the ICS 
UE 

SDP: The SDP contains preconfigured set of codecs supported by the MGW. 
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16. SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 
There is no ICS specific content in this response. 

17. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) - see example in table A.4.2-17 

The SIP INVITE request is routed towards the SCC AS. 

Table A.4.2-17: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 



INVITE tel:+l-212-555-6666 SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2 . 0/UDP 

icscf 1 .homel .net ;branch=z9hG4bKdwe534 , SIP/2 . 0/UDP mgcf 1 .homl .net ;branch=z9hG4bKnashds7 
Max-Forwards: 68 
Route : <sip:sccasl .homel .net :lr>, <sip:scscfl .homel .net; lr>;orig-dialog- 

id="yuf lsae8 0r3rb3fh31ondyr82 9cnyr3 81cn93 2YDWref OwO-wwtg374" 
Record-Route : <sip : scscf 1 . homel . net : lr> 
P-Asserted-Identity: <tel: +l-212-555-llll> 
P- Charging- Function-Addresses : ccf = [5555 : :b99 : c88 :d77 : e6 6] ; ccf = [5555 : : a55 :b44 : c3 3 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
P-Charging-Vector : icid-value="AyretyU0dm+S02IrT5tAFrbHLso=023551024" ; orig-ioi="type 

3homel .net" ; orig-ioi= "homel .net" 
P-Access-Network-Info : 
Privacy: none 

From: <tel: +l-212-555-llll>; tag=171828 
To: 

Call-ID: 

Cseq: 127 INVITE 
Supported: 
Require : 
Proxy-Require : 
Accept-Contact : 
P-Asserted-Service : 
Security-Verify: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v=0 
o= 
s = 
c= 

t= 

m= 
b= 



18. SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 

There is no ICS specific content in this response. 
19-28. These steps are identical to steps 18-27 described in subclause A.4.1. 
29-30. SIP 200 (OK) response (SCC AS to MGCF via intermediate IM CN subsystem entities) 

The SDP answer received in the SIP 200 (OK) response is routed to the MGCF via the intermediate IM CN 

subsystem entities. 

31. ISUP ANM message (MGCF to MSC Server not enhanced for ICS) 
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On receipt of the SIP 200 (OK) response, the MGCF generates an ISUP ANM message and sends this to the 
MSC Server not enhanced for ICS. 

There is no ICS specific content in this message. 

32-33. These steps are identical to steps 30-31 described in subclause A.4.1. 

34-35. SIP ACK request (MGCF to SCC AS via intermediate IM CN subsystem entities) 

On receipt of the SIP 200 (OK) response, the MGCF sends a SIP ACK request to the SCC AS via the 
intermediate IM CN Subsystem entities. 

There is no ICS specific content in this request. 

36-41. These steps are identical to steps 34-39 described in subclause A.4.1. 

A.4.3 Signalling flows for CS UE origination when using an IVISC 
Server enhanced for ICS — multiple codecs used 

Figure A.4.3- 1 shows the origination of a call from a CS UE which uses NAS signalling towards the MSC Server 
enhanced for ICS. The CS UE is controlled by an MSC Server enhanced for ICS. In this example the CS UE supports 
more than one speech codec. The MSC Server enhanced for ICS is supporting codec negotiation. The MSC Server is 
enhanced for ICS and is capable of translating NAS signalling received from the CS UE to SIP and vice versa. 
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Figure A.4.3-1 : CS UE Origination withi CS media whien using an IVISC Server enhianced for ICS - 

multiple codecs used 

The details of the signalling flows are as follows: 

1 . SETUP message (CS UE to MSC Server enhanced for ICS) 

As a result of some stimulus to establish a session with voice media, the CS UE initiates service control 
signalling towards the MSC Server enhanced for ICS by sending a SETUP message. 

Specifically for this signalling flow, the SETUP message includes: 

Called Party Number information element = [(Numbering plan identifier = ISDN/telephony numbering plan), 
(type of number = international number ), (Number digits =12125552222)] 

Bearer Capability information element = [(information transfer capability = speech), (speech versions = PR 
AMR, GSM EFR, GSM FR)] 

- Supported Codec List information element = { [(SysID 1 = UMTS), (Codec Bitmap for SysID 1 = UMTS 
AMR 2)], [(SysID 2 = GSM), (Codec Bitmap for SysID 2 = FR AMR, GSM EFR, GSM FR)] } 

The MSC Server enhanced for ICS knows the calling party number corresponding to the CS UE 

2. Call proceeding message (MSC Server enhanced for ICS to CS UE) 

The MSC Server enhanced for ICS acknowledges the receipt of the SETUP message by sending a call 
proceeding message to the CS UE. 

3-4. Provide IP addresses and RTP information 

The MSC Server enhanced for ICS provides the media gateway with the possible codecs. The MGW provides 
the MSC Server enhanced for ICS with media information eg IP information and RTP information. 

5. SIP INVITE request (MSC Server enhanced for ICS to IM CN subsystem entities) - see example in 
table A.4.3-5. 
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Table A.4.3-5: SIP INVITE request (MSC Server enhanced for ICS to IMS CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP emscl.homel.net;branch=z9hG4bK332b23 .1 

Max- Forwards : 68 

Route : sip : orig®scscf 1 . homel . net ; lr> 

P- Asserted- Identity: <sip :user2_publicl®homel .net>,<tel:+358-50-4821437> 

P-Access-Network-Info:3GPP-UTRAN-TDD; utran-cell-id-3gpp=2 34151D0FCEll ;np 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 

Privacy: none 

From: <sip :user2_publicl®homel .net>; tag=17182 8 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj49033 3 

Cseq: 127 INVITE 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims . icsi .mmtel 

Accept -Contact : * ; +g. 3gpp . icsi -ref="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Supported: lOOrel, precondition, gruu, 199 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip :user2_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims .icsi .mmtel" ; +g. 3gpp. ics=" server" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 49152 RTP/AVP 97 98 99 100 

b=AS:25 .4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR/8000/1 

a=fmtp:97 mode-set=0 , 2 , 4 , 7; mode-change-period=2 

a=rtpmap:98 GSM-EFR/8000/1 

a=rtpmap:99 GSM/8000/1 

a=ptime : 20 

a=rtpmap:100 telephone -event 

a=maxptime : 24 



Request-URI: UAI PSI DN as received in the SETUP message 

P-Asserted-Identity: The MSC Server enhanced for ICS enhanced for ICS inserts the tel-URI containing the 
subscriber number stored in the MSC. 

Accept-Contact: The MSC Server enhanced for ICS includes the mmtel feature tag in the INVITE request . 

P-Asserted -Service: The MSC Server enhanced for ICS includes the mmtel ICSI value in the INVITE request. 

Contact: The MSC Server enhanced for ICS includes the GRUU received at registration, the feature tag 
g.3gpp. icsi-ref set to "urn%3Aurn-7%3gpp-service. ims. icsi. mmtel" and the media 

SDP: The MSC Server enhanced for ICS includes the codecs and IP addresses and port address as received from 
the MOW. 

6. SIP 100 (Trying) response (intermediate IM CN subsystem entities to MSC Server enhanced for ICS) 

The intermediate IM CN subsystem entities respond to the MSC Server enhanced for ICS with a SIP 100 
(Trying) response 

There is no ICS specific content in this response. 

7. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served CS user and as a result routes the SIP INVITE request 
towards the SCC AS. 

8. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) - see example in table A.4.3-8 
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Table A.4.3-8: SIP INVITE request (IM CN subsystem entities to SCC AS) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, 

SIP/2 . 0/UDP emscl .homel .net;branch=z9hG4bK332b23 . 1 

Max- Forwards : 67 

Route : <sip : sccas .homel .net; lr>, <sip : Cb0 3a0s0 9a2sdfglkj4 90 3 3 3@scscf 1 .homel .net; lr>;orig- 

dialog-id="0:73 935718_92645110-712 786jd2463 953 02d-zKE" 
Record-Route : <sip : scscf 1 . homel . net ; lr> , 
P-Asserted- Identity : 
P-Access-Network-Info : 
P-Charging-Vector : 
From: 
To: 

Call-ID: 
Cseq: 

P-Asserted-Service : 
Accept-Contact : 
Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v=0 
o= 
s= 
c= 

t= 

m 
b 
a 
a 
a 
a 
a 
a 
a 
a 
a 
a 



9. SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 
There is no ICS specific content in this response. 
10 SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.4.3-10 
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Table A.4.3-10: SIP INVITE request (SCC AS to IMS CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r5 , 

SIP/2 .0/UDP scscfl. homel. net ;branch=z9hG4bK332b23 .1, 

SIP/2 .0/UDP emscl. homel. net ;branch=z9hG4bK332b23 .1 

Max- Forwards : 66 

Route: <sip:cb03a0s09a2sdfglkj490333®scscf 1 .homel .net ; lr>;orig-dialog-id="0 : 73 93 5 718_92 64 5110- 
712 7 86jd2463 953 02d-zKE" 

Record-Route : <sip : sccas . homel . net ; lr> 

P-Asserted- Identity : 

P-Access-Network-Info : 

P-Charging-Vector : 

Privacy: 

From: <sip : user2_publicl@homel . net> ; tag=274890 

Call-ID: 

Cseq: 

Supported: 

Accept : 

Contact : <sip :user2_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

P-Asserted-Service : 

Accept-Contact : 

Allow: 

Content-Type : 

Content-Length: (...) 

v=0 

o= 

s= 

c= 

t= 

m 
b 
a 
a 
a 
a 
a 
a 
a 
a 
a 
a 



1 1. SIP 100 (Trying) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities respond to the SCC AS with a SIP 100 (Trying) response. 
There is no ICS specific content in this response. 

12. SIP INVITE request (intermediate IM CN subsystem entities to IMS UE) 

The intermediate IM CN subsystem entities route the SIP INVITE request to IMS UE. 

13. SIP 100 (Trying) response (IMS UE to intermediate IM CN subsystem entities) 

IMS UE responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 

There is no ICS specific content in this response. 

14 SIP 183 (Session Progress) response (IMS UE to intermediate IM CN subsystem entities) - see example in 
table A.4.3-14 



£75/ 



3GPP TS 24.292 version 8.4.0 Release 8 71 ETSI TS 1 24 292 V8.4.0 (201 0-01 ) 

Table A.4.3-14: SIP 183 (Session Progress) response (IMS UE to intermediate IM CN subsystem 

entities) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 2 . homel . net ;branch=z9hG4bK240f 34 . 1 , 
SIP/2 .0/UDP scscf2 .homel. net ;branch=z9hG4bK332b23 .1, 
SIP/2 .0/UDP SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r5 , 
SIP/2 .0/UDP scscfl. homel. net ;branch=z9hG4bK332b23 .1, 
SIP/2 .0/UDP emscl. homel. net ;branch=z9hG4bK332b23 .1 

Record- Route : <sip : pcscf 2 .homel .net; lr>,<sip:scscf2 .homel .net; lr>, 
<sip : scscfl . homel . net ; lr> , <sip : sccas . homel . net ; lr> 

P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCEll 
P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" 
Privacy: none 

From: < sip : user2_publicl@homel . net >;tag=274890 
To: <sip:tel: +1-212 -555 -2222 >;tag=4fa328 
Call-ID: 
CSeq: 

Require: 10 Orel, precondition 

Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 950e-4 8a5-4a74-8d99- 
ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 
o= 
s = - 
c = 

t= 

m=audio 49152 RTP/AVP 97 100 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR/8000/1 

a=fmtp:97 mode-set=0 , 2 , 4 , 7 ; mode-change-period=2 

a=rtpmap:100 telephone-event 

a=maxptime : 24 



15-17. SIP 183 (Session Progress) response (From IMS UE to MSC Server enhanced for ICS via IM-CN 
subsystem) 

The SIP 183 (Session Progress) response is routed towards the MSC Server enhanced for ICS via the 
intermediate IM CN subsystem entities. 

18. SIP PRACK request and SIP 200 (OK) response see example in table A.4.3-18. 

After the speech codec has been determined the MSC Server enhanced for ICS indicates that precondition is met. 
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Table A.4.3-18: PRACK request (from MSC Server enhanced for ICS to intermediate IIUI CN entities) 



PRACK <sip: :user2_publicl®home2 .net ;gr=urn:uuid: 2ad8950e-48a5-4a74-8d99-ad76cc7f c74> 

Via: SIP/2 .0/UDP emscl . homel . net ;branch=z9hG4bK3 3 2b2 3 .1 

Max-Forwards: 70 

P-Access-Network-Info : 

Route : : <sip : scscf 1 . homel . net> , <sip : sccasl . homel . net> ; <sip : scscf 2 . homel . net ; lr> 
<sip;pcscf 1 .homel .net ; lr> 

From: 

To: 

Call-ID: 

Cseq: 

Contact : <sip :user2_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics=" server" 

Content-Type : 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: ccc : ddd 

t = 

m=audio 49152 RTP/AVP 97 100 

a=curr:qos local sendrececv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes 

a=rtpmap:100 telephone-event 

a=maxptime : 240 



19-20 Setup radio bearer 

At the receipt of the SDP answer with the codec the MSC Server enhanced for ICS indicates the selected codec 
to the MGW. The MGW releases earlier booked codecs. In this scenario the bearer is set up to the CS UE. 

21 RAB Assignment 

The MSC Server enhanced for ICS sets up the radio bearer. It indicates in the NAS synchronisation indicator bit 
the selected codec to the CS UE. 

22-24. SIP PRACK 200 (OK) (PRACK) 

The PRACK request and its corresponding 200 are sent between MSC Server enhanced for ICS and the IMS UE. 

25-28. SIP 180 (Ringing) response (IMS UE to MSC Server enhanced for ICS via intermediate IM CN 
subsystem entities) 

IMS UE responds to the received SIP INVITE request with a SIP 180 (Ringing) response and alert UE 2. 

The response contains no SDP body and contains no ICS specific content. 

In this example the SCC AS includes in the Contact header field the contents of the Contact header field received 
in the SIP 180 (Ringing) response from the terminating side. 

29-30. Send ringing tone. 

At the receipt of the 180 (Ringing) response the MSC Server enhanced for ICS orders the MGW to send a 
ringing tone towards CS UE. 

31 Alerting (MSC Server enhanced for ICS to CS UE) 

The MSC Server enhanced for ICS sends an alerting message to the CS UE. 

32-35 SIP 200 (OK) (INVITE) from IMS UE to MSC Server enhanced for ICS via intermediate IM CN 
subsystem entities 

When IMS UE answers the call the IMS UE sends a SIP 200 (OK) response to the received SIP INVITE request. 
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In this example the SCC AS includes in the Contact header field the contents of the Contact header field received 
in the SIP 200 (OK) response from the terminating side. 

36-39 SIP ACK request (from IMS UE to MSC Server enhanced for ICS via intermediate IM CN subsystem 
entities) 

40-41. Through connection in both directions 

At the receipt of the 200 (OK) (INVITE) the MSC Server enhanced for ICS through connect in both direction. 

42. CONNECT message (MSC Server enhanced for ICS to CS UE) 

The MSC Server enhanced for ICS maps the received SIP 200 (OK) response to a CONNECT message. 
There is no ICS specific content in this message. 

43. CONNECT ACKNOWLEDGMENT (ICS UE A to MSC Server enhanced for ICS) 

The ICS UE A sends a CONNECT ACKNOWLEDGMENT message upon receiving the CONNECT message. 
There is no ICS specific content in this request. 

A.4.4 Signalling flows for CS UE origination when using an IVISC 
Server enhanced for ICS - one codec used 

Figure A.4.4- 1 shows the origination of a call from a CS UE which uses NAS signalling towards the MSC Server 
enhanced for ICS. The CS UE is controlled by an MSC Server enhanced for ICS. In this example the CS UE supports 
one speech codec. The MSC Server enhanced for ICS is not supporting codec negotiation. The MSC Server is enhanced 
for ICS and is capable of translating NAS signalling received from the CS UE to SIP and vice versa. 
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Figure A.4.4-1 : CS UE Origination with CS media using an IVISC Server enhanced for ICS - one codec 

used 

The details of the signalling flows are as follows: 

1 . SETUP message (CS UE to MSC Server enhanced for ICS) 

As a result of some stimulus to establish a session with voice media, The CS UE initiates service control 
signalling towards the MSC Server enhanced for ICS by sending a SETUP message. 

Specifically for this signalling flow, the SETUP message includes: 

Called Party Number information element = [(Numbering plan identifier = ISDN/telephony numbering plan), 
(type of number = international number ), (Number digits =12125552222)] 

Bearer Capability information element = [(information transfer capability = speech)] 

The MSC Server enhanced for ICS knows the calling party number corresponding to the UE. 

2. Call proceeding message (MSC Server enhanced for ICS to CS UE) 

The MSC Server enhanced for ICS acknowledges the receipt of the SETUP message by sending a call 
proceeding message to the CS UE. 
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3-4. Interaction with the MGW to get media information eg address and port information is performed. 

5. RAB Assignment(From MSC Server enhanced for ICS to the CS UE) 

The MSC Server enhanced for ICS will send the selected codec to the CS UE in NAS synchronisation indicator 
bit in the RAB assignment message. 

6. SIP INVITE request (MSC Server enhanced for ICS to IM CN subsystem entities) for detailed description 
see table A.4.4.6 

Table A.4.4-6: SIP INVITE request (MSC Server enhanced for ICS to IMS CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP emscl.homel.net;branch=z9hG4bK332b23 .1 

Max-Forwards: 68 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P- Asserted- Identity: <tel : +l-212-555-llll> 

P-Access -Network- Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=2 34151D0FCEll ;np 

Privacy: none 

From: <sip :user2_publicl@homel .net>; tag=17182 8 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims . icsi .mmtel 

Accept -Contact : * ; +g. 3gpp . icsi -ref="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Supported: lOOrel, precondition, gruu, 199 

Contact : <sip :user2_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims .icsi .mmtel" ; +g. 3gpp. ics=" server" 

P-Access-Network-Info:3GPP-GERAN; utran-cell-id-3gpp=234151D0FCEll 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 49152 RTP/AVP 97 100 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR/8000/1 

a=fmtp:97 mode-set=0 , 2 , 4 , 7 ; mode-change-period=2 

a=ptime : 20 

a=rtpmap:100 telephone-event 

a=maxptime : 240 



Request-URI: UAI PSI DN as received in the SETUP message. 

P-Asserted-Identity: The MSC Server enhanced for ICS inserts the tel-URI containing the telephone number stored 
in the MSC. 

Accept-Contact: The MSC Server enhanced for ICS includes the mmtel feature tag in the INVITE request. 

P-Asserted-Service: The MSC Server enhanced for ICS includes the mmtel ICSI value in INVITE request. 

Contact: The MSC Server enhanced for ICS includes the GRUU received at registration, the media feature tag 
g.3gpp. icsi-ref set to "urn%3Aurn-7%3gpp-service. ims. icsi. mmtel" and the feature tag g.3gpp.ics set to "server". 

SDP: The MSC Server enhanced for ICS includes the codec and IP addresses and port address as received from the 
MGW. 

7. SIP 100 (Trying) response (intermediate IM CN subsystem entities to MSC Server enhanced for ICS) 

The intermediate IM CN subsystem entities respond to the MSC Server enhanced for ICS with a SIP 100 
(Trying) response. 
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There is no ICS specific content in this response. 

8. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served CS user and as a result routes the SIP INVITE request 
towards the SCC AS. 

9. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) - see example in table A.4.4-9. 

Table A.4.4-9: SIP INVITE request (IMS CN subsystem entities to SCC AS) 



INVITE tel:+l-212-555-2222 SIP/2.0 

via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1 

SIP/2 . 0/UDP emscl .homel .net;branch=z9hG4bK332b23 .1, 

Max-Forwards: 67 

Route : <sip:sccas .homel .net ; lr>, <sip : Cb0 3a0s0 9a2sdfglkj4 90 3 3 3@scscf 1 .homel .net; lr>;orig- 

dialog-id="0:73 935718_92645110-712 786jd24 63 953 02d-zKE" 
Record-Route : <sip : scscf 1 . homel . net ; lr> 
P-Asserted- Identity : 
P-Access-Network-Info : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

P-Asserted-Service : 
Accept-Contact : 
Supported: 
Contact : 
Allow: 

P-Access-Network-Inf o : 
P-Charging-Vector : 
Content-Type : 
Content-Length: (...) 

v=0 
o= 
s= 
c = 

t= 

m= 



10. SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 
There is no ICS specific content in this response. 

1 1. SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.4.4-11. 
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Table A.4.4-11 : SIP INVITE request (SCC AS to IMS CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r5 , 

SIP/2 .0/UDP scscfl. homel. net ;branch=z9hG4bK332b23 .1 

SIP/2 .0/UDP emscl. homel. net ;branch=z9hG4bK332b23 .1 

Max- Forwards : 66 

Route: <sip:cb03a0s09a2sdfglkj490333®scscf 1 .homel .net ; lr>;orig-dialog-id="0 : 73 93 5 718_92 64 5110- 
712 7 86jd2463 953 02d-zKE" 

Record-Route : <sip : sccas . homel . net ; lr> 

P-Asserted- Identity : 

Privacy: 

From: <sip :user2_publicl@homel .net>; tag=2 74 8 90 

To: 

Call-ID: 

Cseq: 

Supported: 

Contact : <sip :user2_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

P-Asserted- Service: 

Accept-contact : 

Allow: 

P-Access-Network-Info : 

P-Charging-Vector : 

Content-Type : 

Content-Length: (...) 

v=0 

o= 

s= 

c= 

t= 



12. SIP 100 (Trying) response (intermediate IM CN subsystem entities to SCC AS) 

The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 
There is no ICS specific content in this response. 

13. SIP INVITE request (intermediate IM CN subsystem entities to IMS UE) 

The intermediate IM CN subsystem entities route the SIP INVITE request to IMS UE. 

14. SIP 100 (Trying) response (UE B to intermediate IM CN subsystem entities) 

UE B responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 

There is no ICS specific content in this response. 

15-18. SIP 180 (Ringing) response (UE B to MSC Server enhanced for ICS via intermediate IM CN 
subsystem entities) 

UE B responds to the received SIP INVITE request with a SIP 180 (Ringing) response and alerts IMS UE. The 
response contains no SDP body and contains no ICS specific content. 

In this example the SCC AS includes in the Contact header field the contents of the Contact header field received 
in the SIP 180 (Ringing) response from the terminating side. 

19-20. Send ringing tone. 

At the receipt of the 180 (Ringing) response the MSC Server enhanced for ICS orders the MGW to send a 
ringing tone towards CS UE. 
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21. Alerting (MSC Server enhanced for ICS to CS UE) 

The MSC Server enhanced for ICS sends an alerting message to the UE. 

22-25 SIP 200 OK (INVITE) from MSC Server enhanced for ICS to IMS UE via intermediate IM CN 
subsystem entities 

IMS UE sends a SIP 200 (OK) response to the received SIP INVITE request when IMS UE answers the call. The 
200 (OK) also include the SDP answer. 

In this example the SCC AS includes in the Contact header field the contents of the Contact header field received 
in the SIP 200 (OK) response from the terminating side. 

26-27- Through connection in both directions 

At the receipt of the 200 (OK) (INVITE) the MSC Server enhanced for ICS orders the MOW to through 
connects in both directions. 

28. CONNECT message (MSC Server enhanced for ICS to CS UE) 

The MSC Server enhanced for ICS maps the received SIP 200 (OK) response to a CONNECT message. There is 
no ICS specific content in this message. 

29. CONNECT ACKNOWLEDGMENT (CS UE to MSC Server enhanced for ICS) 

The CS UE A sends a CONNECT ACKNOWLEDGMENT message upon receiving the CONNECT message. 

30-33. SIP ACK request (MSC Server enhanced for ICS to IMS UE via intermediate IM CN subsystem 
entities) 

Upon receiving the CONNECT ACKNOWLEDGEMENT from the CS UE A, the MSC Server enhanced for 
ICS forwards a SIP ACK request to the SCC AS via the intermediate IM CN Subsystem entities. 

There is no ICS specific content in this request. 

A.4.5 Signalling flows for CS UE origination when using an IVISC 
Server not enhanced for ICS 

Figure A.4.5-1 shows the origination of a call in the CS domain when using an MSC server not enhanced for ICS. The 
originating UE can be an ICS UE or can be a UE without ICS capabilities. 
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Figure A.4.5-1 : CS UE origination when using an IVISC Server not enhanced for ICS 

The details of the signalhng flows are as follows: 
1 Determination of call establishment domain 
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As a result of some stimulus to establish a full-duplex, voice-only call, the UE based on a combination of user 
policy, and access technology availability, decides to establish the call using the CS domain. 

2. SETUP message (UE to VMSC) 

After establishment of the MM connection, the UE initiates the CS call towards the destination UE by sending 
out the SETUP message. 

Specifically for this signalling flow, the SETUP message includes: 

Called Party Number information element = [(Numbering plan identifier = ISDN/telephony numbering plan), 
(type of number = international number ), (Number digits = 12125552222)] 

Bearer Capability information element = [(information transfer capability = speech), (speech versions = FR 
AMR, GSM EFR, GSM FR)] 

- Supported Codec List information element = { [(SysID 1 = UMTS), (Codec Bitmap for SysID 1 = UMTS 
AMR 2)], [(SysID 2 = GSM), (Codec Bitmap for SysID 2 = FR AMR, GSM EFR, GSM FR)] } 

The VMSC knows the calling party number corresponding to the UE. 

3. Origination triggers 

4. Redirection to IM CN subsystem 

The call is redirected to the IM CN subsystem. The mechanism for redirection is out of scope of ICS 
requirements and can be based upon the use of an IP Multimedia Routing Number (IMRN) for redirecting the 
signalling towards the SCC AS. How an IMRN is retrieved is outside the scope of this specification. 

5. ISUP lAM (VMSC to MGCP) 

The VMSC initiates the CS call towards the MGCF by sending out the lAM message. 

Specifically for this signalling flow, the lAM includes: 

Called Party Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of 
number = international number ), (Number digits = 12415553333)] 

Calling Party Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of 
number = international number ), (Number digits = 121255511 1 1)] 

USI parameter = 3.1 kHz audio 

The Called Party Number parameter represents the IMRN allocated for this call. 

6. SIP INVITE request (MGCF to intermediate IM CN subsystem entities) - see example in table A.4.5-6 

The MGCF initiates a SIP INVITE request, containing an initial SDP to the intermediate IM CN subsystem 
entities. 

Table A.4.5-6: SIP INVITE request (MGCF to intermediate IM CN subsystem entities) 



INVITE tel:+l-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcfl.homel.net;branch=z9hG4bK779s24 . 

Max- Forwards : 7 

Route : <sip : icscf l_s . homel . net ; lr> 

P-Asserted- Identity: <tel : +1-212 -555- 1111> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: none 

From: <tel: +1-212- 555 -llll>;tag=171828 

To: <tel:+l-212-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Contact : <sip :mgcf 1 .homel .net>; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 
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o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 



Request-URI: 



Contains the IMRN, as obtained from CS Networks signalling. 



P-Asserted-Identity: The MGCF inserts the tel URL containing the subscriber number, as received from the CS 
network. 



SDP: 



The SDP contains a preconfigured set of codecs supported by the MGW based on what is 
received in the ISUP. The codecs selected are speech codecs. See table 10a of 
3GPPTS 29.163 [10] 



7. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) - see example in table A.4.5-7 

The IMRN is a PSl. The intermediate IM CN subsystem entities are configured to route this PSI to the SCC AS. 
In this particular case, the I-CSCF performs the routeing over the Ma interface. For this example, there is no 
IBCF before the I-CSCF and no intermediate entities Record-Route the request. 



Table A.4.5-7: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 



INVITE tel:+l-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcf 1 . homel . net ;branch=z9hG4bK779s24 . , SIP/2. 0/UDP 

icscf l_s .homel .net ;branch=z9hG4bK312a32 . 1 
Max- Forwards : 69 
Route: <sip : sccas .homel .net ; lr> 
P-Asserted- Identity : 
P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=type 

3homel.net; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



8. SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities) 

There is no ICS specific content to this response. 
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The sec AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 

9. Retrieve original calling and called party information 

The sec AS acts as a routeing B2BUA. The SCC AS retrieves the original called party number and calling 
party number associated with the IMRN and places the called party number in the Request-URI and the To 
header field of the outgoing request. 

How to retrieve the original called party and calling party numbers associated with the IMRN are considered to 
be out of scope of this specification. 

10. SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.4.5-10 

The SCC AS forwards the SIP INVITE request to the S-CSCF serving the originating user within the IM CN 
subsystem. In this case it is assumed that the user is registered within the IM CN subsystem. 

In this example the SCC AS includes the contents of the Contact header from the received SIP INVITE request 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. 

Table A.4.5-10: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2 . 0/UDP;branch=z9hG4bK312a32 .1 

Max-Forwards: 68 

Route : <sip:s-cscf .homel .net; lr;orig> 

Record-Route : <sip : sccas . homel . net ; lr> 

P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=Type 

3homel .net 
Privacy: 

From: <tel:+l-212-555-llll>;tag=2 74 8 90 
To: <tel:+l-212-555-2222> 
Call-ID: dcl4bltl0b3teghmlk501444 
Cseq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



Contact: In this example the SCC AS includes the contents of the Contact header from the received SIP INVITE 
request 

11. SIP 100 (Trying) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities respond to the SCC AS with a SIP 100 (Trying) response. 
There is no ICS content to this response. 

12. SIP INVITE request (intermediate IM CN subsystem entities to terminating side processing) - see 
example in table A.4.5-12 
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The intermediate IM CN subsystem entities route the SIP INVITE request to the terminating side processing. In 
this example, there is no intermediate IBCF and none of the intermediate entities Record-Route. 

Table A.4.5-12: SIP INVITE request (intermediate IM CN subsystem entities to terminating side 

processing) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2 . 0/UDP;branch=z9hG4bK312a32 .1 

Max-Forwards : 68Record-Route : <sip : sccas . homel . net ; lr> 

P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: 

From: 

To: 

Call-ID: 

Cseq: 

Supported: 

Contact : 

Allow: 

Content-Type : 

Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



13. SIP 100 (Trying) response (terminating side processing to intermediate IM CN subsystem entities) 

The terminating side processing responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) 
response. 

There is no ICS specific content to this response. 

14. SIP 180 (Ringing) response, ISUP ACM and ALERTING message (terminating side processing to VCC 

UE) 

The call is successfully delivered to the terminating UE, which begins alerting the user. Normal SIP, ISUP and 
access signalling messages are transferred to indicate this is occurring. At or before this time, completion of 
negotiation of the bearer (e.g. as indicated by SDP in SIP) occurs. There is no ICS specific actions associated 
with this step. 

The sec AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. 

In this example the SCC AS includes in the Contact header field the contents of the Contact header field received 
in the SIP 180 (Ringing) response from the terminating side. 

15. SIP 200 (OK) response (terminating side processing to intermediate IM CN subsystem entities) 

A SIP 200 (OK) response is received from the terminating side processing by the intermediate IM CN subsystem 
entities. 

There is no ICS specific content to this response. 

16. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS. 
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There is no ICS specific content to this response. 

17. SIP 200 (OK) response (SCC AS intermediate to IM CN subsystem entities) 

The SCC AS forwards the SIP (200) OK response back to the intermediate IM CN subsystem entities. 

The UE modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID header fields from one side of the B2BUA to the other. 

In this example the SCC AS includes in the Contact header field the contents of the Contact header field received 
in the SIP 200 (OK) response from the terminating side 

There is no ICS specific content to this response. 

18. SIP 200 (OK) response (intermediate IM CN subsystem entities to MGCF) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the MGCF. 
There is no ICS specific content to this response. 

19. ISUP ANM (MGCF to VMSC) 

On receipt of the SIP 200 (OK) response, the MGCF generates an ISUP ANM message and sends this to the 
VMSC. 

There is no ICS specific content to this response. 

20. CONNECT message (VMSC to UE) 

The VMSC sends a CONNECT message to the UE. 
There is no ICS specific content to this response. 

21. CONNECT ACKNOWLEDGE message (UE to VMSC) 

The UE generates the CONNECT ACKNOWLEDGE message on receipt of the CONNECT message. 
There is no ICS specific content to this response. 

22. SIP ACK request (MGCF to intermediate IM CN subsystem entities) 

The MGCF generates a SIP ACK request on receipt of the SIP 200 (OK) response and sends it back to the 
intermediate IM CN subsystem entities. 

There is no ICS specific content to this response. 

23. H.248 interaction with the MGW 

The MGCF interacts with the MGW for the necessary resource allocation. 

24. SIP ACK request (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 
There is no ICS specific content to this response. 

25. SIP ACK request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS forwards the SIP ACK request back to the intermediate IM CN subsystem entities. 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. 

There is no VCC specific content to this response. 

26. SIP ACK request (intermediate IM CN subsystem entities to terminating side processing) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the terminating side processing. 
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There is no ICS specific content to this response. 

A.5 Signalling flows for call termination 

A.5.1 Signalling flows for termination to a CS UE registered in 
IMS using an MSC Server enhanced for ICS - multiple 
codecs used 

Figure A.5.1-1 shows the termination of a call to a CS UE via the MSC Server enhanced for ICS. Codec negotiation is 
performed. 
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Figure A.5.1-1 : CS UE Termination with CS media using an IVISC Server enhanced for ICS (with codec 

negotiation) 
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The details of the signalling flows are as follows: 

1 . SIP INVITE request (from the originating IM CN subsystem to intermediate IM CN subsystem entities) - 
see example in table A.5.1-1 

The SIP INVITE request is sent by the originating IM CN subsystem to the intermediate IM CN subsystem 
entities. 

Table A.5.1-1 : SIP INVITE request (originating IM CN subsystem to intermediate IM CN subsystem 

entities) 



INVITE sip:user2_publicl@homel .net SIP/2.0 

Via: SIP/2. 0/UDP icscf2_s.home2 .net;branch=z9hG4bK871yl2 .1, SIP/2. 0/UDP 
scscf 1. homel.net ;branch=z 9hG4bK3 3 2b2 3 .1, SIP/2 .0/UDP 
pcscf 1 .homel .net;branch=z9hG4bK431h23 .1, SIP/2 . 0/UDP 
[5555 : :aaa:bbb: ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 67 

Route : <sip : scscf 1 . homel . net ; lr> 

Record- Route : <sip:scscfl .home2 .net; lr>, <sip:pcscfl .home2 .net; lr> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-212-555-llll> 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims . icsi .mmtel 

Accept -Contact : * ; +g. 3gpp . icsi -ref="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Privacy: none 

From: <sip :userl_publicl@home2 .net>; tag=17182 8 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, 199 

Accept : applicatiom/sdp, application/3gpp-ims+xml 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi . mmtel "> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 3400 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 



Request-URI: the SIP URI or tel URI of the called party. In this example the SIP URI of the called party is 
included, which might have been translated from a tel URI by the S-CSCF in the originating IM CN subsystem. 

P-Asserted-Service and Contact: the ICSI defined for MMtel is included as this flow assumes a 3GPP R8 IMS 
UE originator. This for example purposes only, the ICSI might not be included for other originator types. 

2. SIP 100 (Trying) response (from intermediate IM CN subsystem entities to the originating IM CN 
subsystem) 
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The intermediate IM CN subsystem entities respond to the originating IM CN subsystem with a SIP 100 
(Trying) response. There is no ICS specific content in this response. 

3. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the CS user and as a result routes the SIP INVITE request towards 
the sec AS. 

4. SIP INVITE request (from intermediate IM CN subsystem entities to SCC AS) - see example in table 
A.5.1-4. 

The intermediate IM CN subsystem entities route the SIP INVITE request to the SCC AS. 
Table A.5.1-4: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 



INVITE sip:user2_publicl@homel .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b33 . 1 , 

icscfl_s.homel.net;branch=z9hG4bK8 71yl2 .1, SIP/2 .0/UDP 

scscf 1 .home2 .net ;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

pcscf l.home2 .net ;branch=z9hG4bK431h2 3 .1, SIP/2 .0/UDP 

[5555 : :aaa:bbb: ccc :ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Max-Forwards: 66 
Route : <sip:sccas .homel .net ; lr>, <sip : cb03a0s09a2sdfglkj4903 33@scscf 1 .homel .net; lr>;orig- 

dialog-id="0:73 935718_92645110-712 786jd2463 953 02d-zKE" 
Record- Route : <sip:scscfl .homel .net; lr>, <sip:scscfl .home2 .net; lr>, <sip : pcscf 1 .home2 .net; lr> 
P-Access-Network-Info : 
P-Asserted- Identity : 
P-Charging-Vector : 
P-Asserted-Service : 
Accept-Contact : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Accept : 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 



5. SIP 100 (Trying) response (from SCC AS to intermediate IM CN subsystem entities) 

The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There is 
no ICS specific content in this response. 
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6. SIP INVITE request (from SCC AS to intermediate IM CN subsystem entities) - see example in 
table A.5.1-6 

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and sends it to the intermediate IM CN subsystem entities. 

Table A.5.1-6: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip:user2_publicl®homel .net SIP/2.0 

Via: SIP/2. 0/UDP sccas .homel .net;branch=z9hG4bKnas34r5 

Max-Forwards: 65 

Route: <sip:cb03aOs09a2sdfglkj490333@scscf 1 .homel .net ; lr>;orig-dialog-id="0 : 73 93 5 718_92 64 5110- 

712 786jd2463 953 02d-zKE "Record-Route :<sip: sccas .homel .net ;lr> 
P-Access-Network-Info : 
P-Asserted- Identity : 
P- Charging- Function- Addresses : ccf = [5555 : :b99 : c88 :d77 : e66] ; ccf = [5555 : : a55 :b44 : c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
P-Charging-Vector : 
P-Asserted-Service : 

Accept -Contact : * ; +g. 3gpp . ics=" server" 
Privacy: 

From: <sip :userl_publicl@home2 .net>; tag=2 74 890 
To: 

Call-ID: 
Cseq: 

Supported: 
Accept : 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 



Via: the SCC AS, acting as a B2BUA, replaces the Via header field with one containing only its own SIP URL 

Contact: In this example the SCC AS includes the contents of the Contact header fi^om the received SIP 
INVITE request No more triggering is required in the initial filter criteria, the IM CN subsystem will route the 
SIP INVITE request to the terminating user. 

7. SIP 100 (Trying) response (from intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities respond to the SCC AS with a SIP 100 (Trying) response. There is 
no ICS specific content in this response. 

8. SIP INVITE request (from intermediate IM CN subsystem entities to MSC Server enhanced for ICS) - see 
example in table A.5.1-8 
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The intermediate IM CN subsystem entities route the SIP INVITE request to the MSC Server enhanced for ICS. 

Table A.5.1-8: SIP INVITE request (intermediate IM CN subsystem entities to MSC Server enhanced 

for ICS) 



INVITE sip:+358504821437@msc2 .homel.net SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK433b44 .1, SIP/2. 0/UDP 

sccas .homel .net ;branch=z9hG4bKnas34r5 
Max- Forwards : 64 
Route: <sip :msc2 .homel .net ; lr> 

Record-Route : <sip : scscf 1 . homel . net ; lr> , <sip : sccas . homel . net ; lr> 
P-Asserted- Identity : 
P-Charging-Function-Addresses : 
P-Charging-Vector : 
P-Asserted-Service : 

P- Called- Party- ID : <sip :user2_publicl@homel .net> 
Accept -Contact : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Accept : 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v=0 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 



Request-URI: the S-CSCF replaces the Request-URI with the registered contact address. 

Editor" s Note: The Request-URI in this request is built from the contents of the Contact URI from the chosen 
route. This has a dependency on the Contact URI used by the MSC Server enhanced for ICS during 
registration. 

9. SIP 100 (Trying) response (from MSC Server enhanced for ICS to intermediate IM CN subsystem 
entities) 

The MSC Server enhanced for ICS responds to the intermediate IM CN subsystem entities with a SIP 100 
(Trying) response. There is no ICS specific content in this response. 

10. SETUP message (from MSC Server enhanced for ICS to CS UE) 

The MSC Server enhanced for ICS identities the subscriber using the Request-URI and initiates the paging 
procedure towards the terminating CS UE. After the CS UE has successfully accessed the network, the MSC 
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Server enhanced for ICS sends a SETUP message towards the CS UE according to 3GPP TS 24.008 [7], 
providing the interworking as described in 3GPP TS 29.292 [24]. 

Specifically for this signalling flow, the SETUP message includes: 

Calling Party BCD Number information element = [(Numbering plan identifier = ISDN/telephony numbering 
plan), (type of number = international number ), (Presentation indicator=presentation allowed), (Screening 
indicator=network provided), (Number digits = 1212551 1 1 1)] 

Bearer Capability 1 information element = [(information transfer capability = speech)] 

11. CALL CONFIRMED message (from CS UE to MSC Server enhanced for ICS) 

The CS UE sends a CALL CONFIRMED message towards the MSC Server enhanced for ICS according to 
3GPP TS 24.008 [7]. Specifically for this signalling flow, the CALL CONFIRMED message includes: 

- Supported Codec List information element = { [(SysID 1 = UMTS), (Codec Bitmap for SysID 1 = UMTS 
AMR2)], [(SysID 2 = GSM), (Codec Bitmap for SysID 2 = FR AMR, GSM EFR, GSM FR)] } 

In this example, no Bearer Capability I information element is returned. 

As the node terminating the out of band transcoder control procedures as specified in 3GPP TS 23.153 [4A], the 
MSC Server enhanced for ICS selects a single selected codec. 

12. Reserve / Configure RTF (from MSC Server enhanced for ICS to CS-MGW) 

The MSC Server enhanced for ICS performs CS-MGW selection and requests the CS-MGW to prepare for 
network side bearer establishment. The MSC Server enhanced for ICS removes the video media description from 
the SDP offer and then requests reservation and configuration of a local RTP endpoint. The MSC Server 
enhanced for ICS also sends the selected speech codec and the remote user plane RTP information received from 
the SDP offer to the CS-MGW. The MSC Server enhanced for ICS receives the local RTP endpoint information 
from the CS-MGW. 

13. SIP 183 (Session Progress) response (from MSC Server enhanced for ICS to intermediate IM CN 
subsystem entities) - see example in table A.5.1-13 

The MSC Server enhanced for ICS returns an SDP answer. The video media description has been removed and 
only the audio media description is included. 
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Table A.5.1-13: SIP 183 (Session Progress) response (MSC Server enhanced for ICS to intermediate 

IM CN subsystem entities) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK433b44 . 1 , SIP/2. 0/UDP 
sccas .homel .net ;branch=z9hG4bKnas34r5 

Record-Route : <sip : scscf 1 . homel . net ; lr> 

P-Asserted- Identity : <sip :user2_publicl@homel .net> 

P- Charging- Vector: icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" 

From: 

To: <tel: +1-212 -555 -2222 >;tag=3 14159 

Call-ID: 

Cseq: 

Require: lOOrel 

Contact : <sip :user2_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics=" server" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 

Rseq: 9021 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933623 2987933623 IN IP6 5555 : : eee : f f f : aaa :bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=video RTP/AVP 98 99 

m=audio 6544 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des : qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



P-Asserted-Identity: the value taken from the P-Called-Party-ID header field in the INVITE request. 

The SDP answer in the 183 (Session Progress) response contains a single selected codec and a request for 
confirmation of when remote preconditions are met. 

14-16. SIP 183 (Session Progress) response (from intermediate IM CN subsystem entities to SCC AS) 

The SIP 183 (Session Progress) response is routed to the originating IM CN subsystem via the SCC AS and 
intermediate IM CN subsystem entities. In this example the SCC AS includes the contents of the Contact header 
from the received SIP 183 (Session Progress) response except the g.3gpp.ics media feature tag which is removed 
by the SCC AS. 

17-20. SIP PRACK request and SIP 200 (OK) response 

The SIP PRACK request and its SIP 200 (OK) response are routed end-to-end between the originating IM CN 
subsystem, intermediate IM CN subsystem entities, SCC AS and MSC Server enhanced for ICS. There is no 
specific ICS content in these messages. In this example the SCC AS includes the contents of the Contact header 
from the received SIP PRACK request. 

21-24. SIP UPDATE request and SIP 200 (OK) response 

When the originating endpoint has completed its resource reservation, the intermediate IM CN subsystem 
entities receive an UPDATE request. The UPDATE request and its SIP 200 (OK) response are routed end-to-end 
between the originating IM CN subsystem, intermediate IM CN subsystem entities, SCC AS and MSC Server 
enhanced for ICS. There is no specific ICS content in these messages. In this example the SCC AS includes the 
contents of the Contact header from the received SIP UPDATE request. 

25. Assignment 

The MSC Server enhanced for ICS performs access bearer assignment. 



£75/ 



3GPP TS 24.292 version 8.4.0 Release 8 93 ETSI TS 1 24 292 V8.4.0 (201 0-01 ) 

For UTRAN access this involves invocation of the Prepare Bearer and Change Through Connection procedures 
with the CS-MGW, followed by sending a RAB ASSIGNMENT REQUEST message to the UTRAN. The NAS 
Synchronization Indicator information element is included to identify the selected codec and codec 
configuration. 

For GERAN access this involves invocation of the Reserve Circuit and Change Through Connection procedures 
with the CS-MGW, followed by sending a ASSIGNMENT REQUEST to the GERAN. 

26. ALERTING message (from CS UE to MSC Server enhanced for ICS) 

The CS UE sends an ALERTING message to the MSC Server enhanced for ICS according to 
3GPPTS 24.008 [7]. 

27. Start tone (from MSC Server enhanced for ICS to CS-MGW) 

The MSC Server enhanced for ICS instructs the CS-MGW to start ringback tone. 

28. SIP 180 (Ringing) response (from MSC Server enhanced for ICS to intermediate IM CN subsystem 
entities) - see example in table A.5.1-28 

The MSC Server enhanced for ICS does not include "lOOrel" in the Require header field as the 180 (Ringing) 
response does not contain SDP and therefore need not be sent reliably. 

Table A.5.1-28: SIP 180 (Ringing) response (MSC Server enhanced for ICS to intermediate IM CN 

subsystem entities) 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK433b44 . 1 , SIP/2. 0/UDP 

sccas2 .home2 .net ;branch=z9hG4bKnas34r5 
From: 

To : <sip : userl_publicl@homel . net> ; tag=314159 
Call-ID: 
Cseq: 

Rseq: 9022 
Content-Length: 



29-31. SIP 180 (Ringing) response (from intermediate IM CN subsystem entities to SCC AS) 

The SIP 180 (Ringing) response is routed to the originating IM CN subsystem via the SCC AS and intermediate 
IM CN subsystem entities. 

32. CONNECT message (from CS UE to MSC Server enhanced for ICS) 

The CS UE sends a CONNECT message to the MSC Server enhanced for ICS according to 3GPP TS 24.008 [7]. 

33. Stop tone and through connect (from MSC Server enhanced for ICS to CS-MGW) 

The MSC Server enhanced for ICS instructs the CS-MGW to stop ringback tone and to through connect the 
bearer. 

34. SIP 200 (OK) response (from MSC Server enhanced for ICS to intermediate IM CN subsystem entities) - 
see example in table A.5.1-34 

Table A.5.1-34: SIP 200 (OK) response (MSC Server enhanced for ICS to intermediate IM CN 

subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK433b44 .1, SIP/2. 0/UDP 
sccas2 .home2 .net ;branch=z9hG4bKnas34r5 

From: 

To : <sip : userl_publicl@homel . net> ; tag=314159 

Call-ID: 

Cseq: 

Contact : < 

sip :user2_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6>; +g. 3gpp . icsi- 
ref ="urn%3Aurn-7%3gpp-service . ims . icsi .mmtel" ; +g. 3gpp. ics=" server" 

Content-Length: 
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Contact: the MSC Server enhanced for ICS includes the GRUU received at registration, the media feature tag 
g.3gpp.icsi-ref set to "urn%3Aurn-7%3gpp-service.ims.icsi.mmtel" and the media feature tag g.3gpp.ics set to 
"server". 

35-37. SIP 200 (OK) response 

The 200 (OK) response is routed to the originating IM CN subsystem via the SCC AS and intermediate IM CN 
subsystem entities. In this example the SCC AS includes the contents of the Contact header from the received 
SIP 200 (OK) response except the g.3gpp.ics media feature tag which is removed by the SCC AS. 

38. CONNECT ACK request (from MSC Server enhanced for ICS to CS UE) 

After through-connecting the traffic channel, the MSC Server enhanced for ICS sends a CONNECT 
ACKNOWLEDGEMENT message to the CS UE according to 3GPP TS 24.008 [7]. 

39-42. SIP ACK request 

A SIP ACK request is routed end-to-end from the originating IM CN subsystem to the MSC Server enhanced for 
ICS. There is no ICS specific content in this message. 

A. 5. 2 Signalling flows for termination to a CS UE not registered in 
IIVIS 

Figure A.5.2-1 shows the termination of a call to a CS UE not registered in the IM CN subsystem. 
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Originating IIVI CN 
subsystem 



Intermediate IIVI 

CN subsystem 

entities 



1. SIP INVITE ► 

-2. SIP 100 (Trying) 

3. IPC evaluation 



sec AS 




-4. SIP INVITE- 



-5. SIP 100 (Trying) 

6. Domain selection 



7. CSRN retrieval 



MGCP 



8. SIP INVITE 

-9. SIP 100 (Trying)— ► 

10. SIP INVITE 

1 1 . SI P 1 00 (Trying)- 



-15. SIP 183 (Session Progress)- 



18. SIP 183 (Session 
Progress) 

19. SIP PRACK/ 

200 (OK) 



23. SIP UPDATE/ 
200 (OK) 



16. SIP 183 (Session 

Progress) 

17. SIP 183 (Session 

Progress) 



20. SIP PRACK/ 
200 (OK) 

21. SIP PRACK/ 
200 (OK) 



24. SIP UPDATE/ 
200 (OK) 

25. SIP UPDATE/ 

200 (OK) 



12. SIP INVITE 1 

-13. SIP100(Trying)- 
14. SIP 183 (Session 
Progress) 



-22. SIP PRACK/200 (OK)- 



26. SIP UPDATE/ 
200 (OK) 



-28. SIP180(Ringing)- 



l-27. SIP180(Ringing) — 



1-31. SIP 180 (Ringing) — 



-29. SIP180(Ringing)H 
1-30. SIP 180(Ringing)- 



-33. SIP 200 (OK)- 



-32. SIP 200 (OK)- 



-36. SIP 200 (OK)- 
37. SIP ACK 



-34. SIP 200 (OK)- 
-35. SIP 200 (OK)- 



-38. SIPACK- 
-39. SIPACK- 



-41.SIPACK- 



Figure A.5.2-1 : CS UE Termination to UE not registered in the IIVI CN subsystem 
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The details of the signalling flows are as follows: 

Steps 1 through 5 are identical to the example is subclause A. 5.1. 

6. Domain selection 

The sec AS acting performs terminating access domain selection based on operator and user preferences, 
registration and call states; in this example, the user is not registered in the IM CN subsystem and the SCC AS 
selects breakout to the CS domain to terminate the call. 

7. CSRN retrieval 

The SCC AS determines the CS domain Routing Number (CSRN). 
NOTE: CSRN retrieval is implementation specific. 

8. SIP INVITE request (from SCC AS to intermediate IM CN subsystem entities) - see example in 
table A.5.2-8 

The SCC AS acting as a routing B2BUA generates a SIP INVITE request. 
Table A.5.2-8: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP sccas .homel .net;branch=z9hG4bKnas34r5 

Max- Forwards : 65 

Route : <sip : Cb0 3a0s0 9a2sdfglkj4 90 3 3 3@scscf 1 .homel .net; lr>;orig-dialog- 

id="O:73 935718_92645110-712 786jd2463 953 02d-zKE" 
Record-Route : <sip : sccas . homel . net ; lr> 
P-Access-Network-Info : 
P-Asserted- Identity : 
P- Charging- Function- Addresses : ccf = [5555 : :b99 : c88 :d77 : e66] ; ccf = [5555 : : a55 :b44 : c3 3 :d22] 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : Gaa : 7bb : 8cc : 9dd] 
P-Charging-Vector : 
P-Asserted-Service : 
Accept-Contact : 
Privacy: 

From: <sip :userl_publicl@home2 .net>; tag=2 74 890 
To: 

Call-ID: 
Cseq: 

Supported: 
Accept : 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 
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Request-URI: the CSRN. 

Via: the SCC AS, acting as a B2BUA, replaces the Via header field with one containing only its own SIP URL 

9. SIP 100 (Trying) response (from intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities respond to the SCC AS with a SIP 100 (Trying) response. There is 
no ICS specific content in this response. 

10. SIP INVITE request (from intermediate IM CN subsystem entities to BGCF) 

The S-CSCF determines the destination is in the CS domain (e.g. after ENUM/DNS translation fails to translate 
the CSRN in tel URI format to a globally routeable SIP URI). The S-CSCF forwards the INVITE request to a 
BGCF in the local network. There is no ICS specific content in this request. 

1 1 . SIP 100 (Trying) response (from BGCF to intermediate IM CN subsystem entities) 

The BGCF responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There is no 
ICS specific content in this response. 

12. SIP INVITE request (from BGCF to MGCF) 

The BGCF analyzes the destination address and allocates a MGCF to handle the termination. The BGCF 
forwards the INVITE request to the MGCF. There is no ICS specific content in this request. 

In this example, the BGCF does not add itself to the Record-Route header field and will therefore not be in the 
session path of subsequent SIP requests. 

13. SIP 100 (Trying) response (from MGCF to BGCF) 

The MGCF responds to the MGCF with a SIP 100 (Trying) response. There is no ICS specific content in this 
response. 

14-18. SIP 183 (Session Progress) response 

The SIP 183 (Session Progress) response is routed to the originating IM CN subsystem via the SCC AS and 
intermediate IM CN subsystem entities. In this example the SCC AS includes the contents of the Contact header 
from the received SIP 183 (Session Progress) response. 

19-22. SIP PRACK request and SIP 200 (OK) response 

The SIP PRACK request and its SIP 200 (OK) response are routed end-to-end between the originating IM CN 
subsystem, intermediate IM CN subsystem entities, SCC AS and MGCF. There is no specific ICS content in 
these messages. In this example the SCC AS includes the contents of the Contact header from the received SIP 
PRACK request. 

23-26. SIP UPDATE request and SIP 200 (OK) response 

When the originating endpoint has completed its resource reservation, the intermediate IM CN subsystem 
entities receive an UPDATE request. The UPDATE request and its SIP 200 (OK) response are routed end-to-end 
between the originating IM CN subsystem, intermediate IM CN subsystem entities, SCC AS and MGCF. There 
is no specific ICS content in these messages. In this example the SCC AS includes the contents of the Contact 
header from the received SIP UPDATE request. 

27-31. SIP 180 (Ringing) response (from MGCF to intermediate IM CN subsystem entities) 

The SIP 180 (Ringing) response is routed to the originating IM CN subsystem via the SCC AS and intermediate 
IM CN subsystem entities. The MGCF does not include "lOOrel" in the Require header field as the 180 (Ringing) 
does not contain SDP and therefore need not be sent reliably. 

32-36. SIP 200 (OK) response 

The 200 (OK) response is routed to the originating IM CN subsystem via the SCC AS and intermediate IM CN 

subsystem entities. 

37-41. SIP ACK request 
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A SIP ACK request is routed end-to-end from the originating IM CN subsystem to the MGCF. There is no ICS 
specific content in this message. 

A. 5. 3 Signalling flows for termination to an ICS UE with CS media 
using Gm reference point when using an MSC server 
enhanced for ICS 

Figure A.5.3-1 shows the termination of a call to an ICS UE using CS bearers controlled through the IM CN subsystem. 
In this example the MSC Server is enhanced for ICS and is capable of translating N AS signalling received from the ICS 
UE to SIP and vice versa. 
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Figure A.5.3-1 : ICS UE termination withi CS media using Gm reference point whien using an lUISC 

Server enhianced for ICS 

The details of the signalling flows are as follows: 

1 . SIP INVITE request (originating IM CN subsystem to intermediate IM CN subsystem entities in 

terminating network) - see example in table A.5.3-1 In this example, the originating UE initiates a voice call 
though its home IM CN subsystem (homel) with a terminating UE which is ICS capable which is in a different 
network (home2). 

Table A.5.3-1 : SIP INVITE request (originating IM CN subsystem to intermediate IM CN subsystem 

entities in terminating network) 



INVITE sip:user2_publicl@homel .net SIP/2.0 

Via: SIP/2. 0/UDP icscfl . homel . net ;branch=z9hG4bK871yl2 . 1 , SIP/2. 0/UDP 
scscf l.home2 .net ;branch=z9hG4bK3 3 2b2 3 .1, SIP/2 .0/UDP 
pcscf l.visited2 .net ;branch=z9hG4bK431h23 .1, SIP/2 .0/UDP 
[5555 : :aaa:bbb: ccc :ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 

Max-Forwards: 67 

Route : <sip : scscf 1 . homel . net ; lr> 

Record- Route : <sip:scscfl .home2 .net; lr>, <sip:pcscfl . visted2 .net; lr> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@home2 .net>, <tel : +l-212-555-llll> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims . icsi .mmtel 

Accept -Contact : * ; +g. 3gpp . icsi -ref="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Privacy: none 

From: <sip :userl_publicl@home2 .net>; tag=17182 8 

To : <sip :user2_publicl@homel .net> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, 199 

Contact : <sip :userl_publicl@home2 .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 7>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi . mmtel "> 

Accept : application/sdp, application/3gpp-ims+xml 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c = IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrcv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



NOTE 1 : This example assumes the session was originated from a 3GPP Release 8 IMS UE and thus includes the 
ICSI value defined for MMTel in the Contact header field and Accept Contact header field. However, 
termination procedures for ICS do not rely upon the MMTel ICSI value being present in the incoming 
request. 

2. SIP 100 (Trying) response (intermediate IM CN subsystem entities to originating IM CN subsystem) 

The intermediate IM CN subsystem entities respond to the originating IM CN subsystem with a SIP 100 
(Trying) response. There is no ICS specific content in this response. 

3. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served ICS user and as a result routes the SIP INVITE request 
towards the SCC AS. 

NOTE 2: for terminating scenario, the SCC AS is configured as the last AS in the terminating iFC chain. 
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4. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) - see example in table A.5.3-4 

As a result of iFC evaluation, the S-CSCF routes the INVITE request to the SCC AS. 

Table A.5.3-4: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 



INVITE sip:user2_publicl®homel .net SIP/2.0 

Via: SIP/2 .0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b33 .1, SIP/2 . 0/UDP 

icscfl. homel.net ;branch=z 9hG4bK8 7 lyl2 .1, SIP/2 .0/UDP 

scscf l.home2 .net ;branch=z9hG4bK3 3 2b2 3 .1, SIP/2 .0/UDP 

pcscf l.visited2 .net ;branch=z9hG4bK431h23 .1, SIP/2 .0/UDP 

[5555 : :aaa:bbb: ccc :ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Max-Forwards: 66 
Route : <sip : sccas . homel . net ; lr> , <sip : cb03a0s09a2sdf glkj 490333@scscf 1 . homel . net ; lr> ; orig- 

dialog-id="O:73 935718_92645110-712 786jd2463 953 02d-zKE" 
Record-Route : <sip : scscf 1 . homel . net ; lr> , <sip : scscf 1 . home2 . net ; lr> , 

<sip : pcscf 1 . visited2 .net ; lr> 
P-Access-Network-Info : 
P-Asserted- Identity : 
P-Charging-Vector : 
P-Asserted-Service : 
Accept -Contact : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Accept : 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v=0 
o=- 
s = - 
c- 

t= 

m= 
b= 



5. SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There is 
no ICS specific content in this response. 

6. Terminating Access Domain Selection 

The SCC AS performs Terminating Access Domain Selection and chooses the CS domain for the setup of the 
media. 

7. SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in Table A.5.3-7. 

The SCC AS, acting as a routing B2BUA, generates a SIP INVITE request based upon the received SIP INVITE 
request and send it to the intermediate subsystem entities. The SDP indicates that the ICS UE B should establish 
a CS media bearer. 
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Table A.5.3-7: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip:user2_publicl®homel .net SIP/2.0 

Via: SIP/2. 0/UDP sccas2 . home2 . net ;branch=z9hG4bKnas34r5 

Max-Forwards: 65 

Route: <sip:cb03a0s09a2sdfglkj490333@scscf 1 .homel .net ; lr>;orig-dialog-id="0 : 73935718_92645110- 

712 7 86jd2463 953 02d-zKE" 
Record-Route : <sip : sccas . homel . net ; lr> 
P-Access-Network-Info : 
P-Asserted- Identity : 
P- Charging- Function-Addresses : ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a5 5:b44:c33:d22]; 

ecf= [5555: :lff :2ee:3dd:4ee] ; ecf= [5555: : Gaa : 7bb : 8cc : 9dd] 
P-Charging-Vector : 
P-Asserted-Service : 

Accept -Contact* ;+g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
Accept -Contact : +* ;g. 3gpp . ics= "principal" /explicit /require 
Privacy: 

From: <sip :userl_publicl@home2 .net>; tag=274890 
To: 

Call-ID: 
Cseq: 

Supported: 
Accept : 
Contact : 
Allow: 

Content-Type : 
Content-Length: 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=PSTN E164 +12125556666 

t = 

m=audio 9 PSTN - 

a=setup :passive 

a=connection : new 

a=curr: qos local none 

a=curr: qos remote none 

a=des : qos mandatory local sendrcv 

a=des : qos mandatory remote sendrcv 

a=inactive 



8. SIP 100 (Trying) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities respond to the SCC AS with a SIP 100 (Trying) response. There is 
no ICS specific content in this response. 

9. SIP INVITE request (intermediate IM CN subsystem entties to ICS UE B) 

The SIP INVITE request is routed towards the called party ICS UE B since further iFC evaluation is not 
necessary. 

10. SIP 100 (Trying) response (ICS UE B to intermediate IM CN subsystem entities) 

The ICS UE B responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There 
is no ICS specific content in this response. 

1 1. SETUP message (ICS UE B to MSC Server enhanced for ICS) 

The ICS UE B inititates bearer setup in the CS domain by sending a SETUP message to the MSC Server 
enhanced for ICS. 

Specifically for this signalling flow, the SETUP message includes: 

Called Party Number information element = = [(Numbering plan identifier = ISDN/telephony numbering 
plan), (type of number = international number ), (Number digits = 1212556666)]. The Called Party Number 
information element is set to the lUA PSI DN. 

Bearer Capability information element = [(information transfer capability = speech), (speech versions = FR 
/VMR, GSM EFR, GSM FR)] 
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- Supported Codec List information element = { [(SysID 1 = UMTS), (Codec Bitmap for SysID 1 = UMTS 
AMR 2)], [(SysID 2 = GSM), (Codec Bitmap for SysID 2 = FR AMR, GSM EFR, GSM PR)] } 

The MSC Server enhanced for ICS knows the calling party number corresponding to the ICS UE B. 

12. CALL PROCEEDING message (MSC Server enhanced for ICS to ICS UE B) 

Upon receipt of the SETUP message from the ICS UE B, the MSC Server enhanced for ICS responds with a 
CALL PROCEEDING message. There is no ICS specific content in this message. 

13. SIP INVITE request (MSC Server enhanced for ICS to intermediate IM CN subsystem entities) - see 
example in table A.5.3-13. 

The MSC Server enhanced for ICS maps the received SETUP message to a SIP INVITE request which is routed 
towards the intermediate IM CN subsystem entities. The INVITE request is addressed to the lUA PSI DN in the 
Request-URL 

Table A.5.3-13: SIP INVITE request (MSC Server enhanced for ICS to intermediate IM CN subsystem 

entities) 



INVITE tel:+l-212-555-6666 SIP/2.0 

Via: SIP/2. 0/UDP msc2 .homel .net;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route: <sip : icscfl .homel .net : lr> 

P- Asserted- Identity: <sip :user2_publicl®homel .net>, <tel:+l-212-555-2222> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=home2 .net 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

P-Access-Network-Info : 

Privacy: none 

From: <sip :user2_publicl®homel .net>; tag=17182 8 

To: <tel:+l-212-555-6666> 

Call -ID: f81d4fae-7dec-lld0-a765-0 0a0c91e6bf6 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, 199 

Contact : <sip :user2_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6>; 

+g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" ; +g. 3gpp. ics=" server" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 



Request-URI: UAI PSI DN as received in the SETUP message. 

P-Asserted-Identity: The MSC Server enhanced for ICS inserts the tel-URI containing the subscriber 
number, as received from the ICS UE B. 

Accept-Contact: The MSC Server enhanced for ICS includes the mmtel media feature tag in the INVITE 
request . 

Contact: The MSC Server enhanced for ICS includes the GRUU received at registration, the media feature tag 
g.3gpp. icsi-ref set to "urn%3Aurn-7%3gpp-service. ims. icsi. mmtel" and the media feature tag g.3gpp.ics set to 
"server". 

SDP: The SDP contains preconfigured set of codecs supported by the MGW. 



£75/ 



3GPP TS 24.292 version 8.4.0 Release 8 1 04 ETSI TS 1 24 292 V8.4.0 (201 0-01 ) 

14. SIP 100 (Trying) response (intermediate IM CN subsystem entities to MSC Server enhanced for ICS) 

The intermediate IM CN subsystem entities respond to the MSC Server enhanced for ICS with a SIP 100 
(Trying) response. There is no ICS specific content in this response. 

15. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) - see example in Table A.5.3-15 

The SIP INVITE request is sent to the SCC AS. 

Table A.5.3-15: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 



INVITE tel:+l-212-555-S666 SIP/2.0 

Via: SIP/2 .0/UDP scscf 1 . homel . net ;branch=z9hG4bK3 32b3 3 .1, SIP/2 .0/UDP 

icscf 1 .homel .net ;branch=z9hG4bK8 71yl2 .1, SIP/2 . 0/UDP msc2 .homel .net ;branch=z9hG4bKnashds7 
Max-Forwards: 68 
Route: <sip:sccas .homel .net : lr>, <sip : scscf 1 .homel .net ; lr>;orig-dialog- 

id="yuf lsae80r3rb3fh31ondyr82 9cnyr3 81cn93 2YDWref 0w0-wwtg3 74" 
Record-Route : <sip : scscf 1 . homel . net ; lr> 
P-Asserted- Identity : 
P-Charging-Vector : 
P-Access-Network-Info : 
Accept -Contact : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Require : 
Proxy-Require : 
Security-Verify: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 

o=- 

s= 

c = 

t= 

m= 

b= 

a= 

a= 

a= 

a= 

a= 



16. SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There is 
no ICS specific content in this response. 

17. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.5.3- 
17. 

The SCC AS responds to the SIP INVITE request with a SIP 200 (OK) response that includes an SDP answer. 
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Table A.5.3-17: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2 .0/UDP scscf2 .home2 .net ;branch=z9hG4bK332b33 .1, SIP/2 .0/UDP 

icscf 2 .home2 .net ;branch=z9hG4bK8 71yl2 .1, SIP/2 . 0/UDP msc2 .home2 .net ;branch=z9hG4bKnashds7 

Record-Route : <sip : sccas . homel . net ; lr> , <sip : scscf 1 . homel . net ; lr> 

P-Access-Network-Info : 

Privacy: none 

From: <tel: +l-212-555-2222>; tag=171828 

To: <tel: +1-212 -555- 6666 >;tag=378959 

Call -ID: f81d4fae-7dec-lld0-a765-0 0a0c91e6bf6 

CSeq: 

Require: 10 Orel, precondition 

Contact : <sip :userl_publicl®home2 .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel"> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933623 2987933623 IN IP6 5555 : : ggg : f f f : aaa : bbb 

s = - 

c = IN IP6 5555 : :ggg:fff :aaa:bbb 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrcv 

a=curr:qos remote sendrcv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=maxptime : 20 



18. SIP 200 (OK) response (intermediate IM CN subsystem to MSC Server enhanced for ICS) 

The intermediate IM CN subsystem entities route the SIP 200 (OK) response to the MSC Server enhanced for 
ICS. 

19. CONNECT message (MSC Server enhanced for ICS to ICS UE B) 

The enhance MSC Server maps the received SIP 200 (OK) response to a CONNECT message. There is no ICS 
specific content in this message. 

20. CONNECT ACKNOWLEDGEMENT message (ICS UE B to MSC Server enhanced for ICS) 

The ICS UE A sends a CONNECT ACKNOWLEDGMENT message upon receiving the CONNECT message. 
There is no ICS specific content in this message. 

21-22. SIP ACK request (MSC Server enhanced for ICS to SCC AS via intermediate IM CN subsystem 
entities) 

The MSC Server enhanced for ICS interworks the received CONNECT ACKNOWLEDGEMENT message to a 
SIP ACK request which is routed to the SCC AS via the intermediate IM CN subsystem entities. There is no ICS 
specific content in this response. 

23-24. SIP 180 (Ringing) response (ICS UE B to SCC AS via intermediate IM CN subsystem entities) 

The ICS UE B responds to the received SIP INVITE request with a SIP 180 (Ringing) response. The response 
contains no SDP body and contains no ICS specific content. The SIP 180 (Ringing) response is routed to the 
SCC AS. 

25-26. SIP 180 (Ringing) response (SCC AS to originating IM CN subsystem via intermediate IM CN 
subsystem entities) 

The SCC AS routes the received SIP 180 (Ringing) response towards the originating network and the calling 
party. 

27. SIP 200 (OK) response (ICS UE B to intermediate IM CN subsystem entities) - see example in 
Table A.5.3-27 
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The ICS UE B responds to the received initial SIP INVITE request with a SIP 200 (OK) response. This SIP 200 
(OK) response includes an SDP answer from the ICS UE and indicates resources have been reserved and the 
dialog can be established. 

Table A.5.3-27: SIP 200 (OK) response (ICS UE B to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . home2 . net ;branch=z9hG4bKf eh9083 , SIP/2. 0/UDP 

scscf 2 .home2 .net ;branch=z9hG4bK3 3 2b44 .1, SIP/2 . 0/UDP sccas2 .home2 .net ;branch=z9hG4bKnas34r5 
Record- Route : <sip : pcscf 2 . visited2 .net; lr>, <sip:scscf2 .home2 .net; lr> 
P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From: <tel: +l-212-555-llll>; tag=171828 
To: <tel:+l-212-555-2222> 
Call -ID: Cb03a0s09a2sdfglkj 490333 
CSeq: 

Require: lOOrel, precondition 
Contact : 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933623 2987933623 IN IP6 5555 : : eee : f f f : aaa : bbb 

s = - 

c=PSTN - - 

t = 

m=audio - PSTN - 

a=setup : active 

a=connection : new 

a=curr:qos local sendrcv 

a=curr:qos remote sendrcv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 



28. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The SIP 200 (OK) response and final SDP answer from the ICS UE is routed towards the SCC AS. 

29. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in Table A.5.3- 
29 

The SCC AS, acting as a B2BUA, generates a SIP 200 (OK) response based upon the SIP 200 (OK) response 
reeceived and is routed towards the intermediate IM CN subsystem entities. This SIP 200 (OK) response 
includes an answer SDP in response to the offer SDP that was received by the SCC AS in the original SIP 
INVITE request. The answer SDP indicates the IP addressed and codecs of the MGW as received by the SCC 
AS during CS bearer setup. 
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Table A.5.3-29: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf2 .home2 .net;branch=z9hG4bKfeh9083, SIP/2. 0/UDP 

scscf 2 .home2 .net ;branch=z9hG4bK3 3 2b44 .1, SIP/2 . 0/UDP sccas2 .home2 .net ;branch=z9hG4bKnas34r5 
Record- Route : <sip ipcscf 2 . visited2 .net; lr>, <sip:scscf2 .home2 .net; lr> 
P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From: <tel: +l-212-555-llll>; tag=171828 
To: <tel:+l-212-555-2222> 
Call -ID: Cb03a0s09a2sdfglkj4903 3 3 
CSeq: 

Require: 10 Orel, precondition 
Contact : 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933623 2987933623 IN IP6 5555 : : eee : f f f : aaa : eee 

s = - 

c=IN IP6 5555 :: eee : fff : aaa : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

a=curr:qos local sendrcv 

a=curr:qos remote sendrcv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=maxptime : 20 



30. SIP 200 (OK) response (intermediate IM CN subsystem entities to originating EM CN subsystem via) 

The SIP 200 (OK) response is routed towards the originating UE via the originating IM CN subsystem. 

31-32. SIP ACK request (originating IM CN subsystem to SCC AS via intermediate IM CN subsystem 
entities and SCC AS) 

The originating IM CN subsystem sends a SIP ACK request to the SCC AS via the intermediate IM CN 
subsystem entities. There is no ICS specific content in this response. 

33-34. SIP ACK request (SCC AS to ICS UE B via intermediate IM CN subsystem entities and SCC AS) 

The SCC AS sends a SIP ACK request to the ICS UE B via the intermediate IM CN subsystem entities. There is 
no ICS specific content in this response. 

A. 5. 4 Signalling flows for termination to an ICS UE with CS media 
using Gm reference point when using an MSC Server not 
enhanced for ICS 

Figure A.5.4-1 shows the termination of a call to an ICS UE using CS bearers controlled through the IM CN subsystem. 
In this example the MSC Server is not enhanced for ICS thus translation at the MGCF of ISUP message to SIP 
messages is required. 
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Figure A.5.4-1 : ICS UE termination with CS media using Gm reference point when using an MSC 

Server not enhanced for ICS 
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The details of the signalling flows are as follows: 

1-12. These steps are identical to steps 1-12 described in subclause A.5.3 (Signalling flows for termination to an 
ICS UE with CS media using Gm reference point when using an MSC Server enhanced for ICS) 

13. ISUP lAM message (MSC Server not enhanced for ICS to MGCF) 

The MSC Server not enhanced for ICS maps the received SETUP message to an ISUP lAM message that is 
routed towards the MGCF. 

Specifically for this signalling flow, the lAM includes: 

Called Party Number parameter = [Numbering plan identifier = ISDN/telephony numbering plan], (type of 
number = international number), (Number digits = 12125556666)]. The Called Party Number is set to the 
UAI PSI DN, as received in the SETUP message. 

Calling Party Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of 
number = international number), (Number digits = 12125552222)] 

14. SIP INVITE request (MGCF to intermediate IM CN subsystem entities) - see example in Table A.5.4-14. 

The MGCF maps the received ISUP lAM message to a SIP INVITE request which is routed towards the 
intermediate IM CN subsystem entities. The INVITE request is addressed to the lUA PSI DN in the Request- 
URI. 

Table A.5.4-14: SIP INVITE request (MGCF to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-6666 SIP/2.0 

Via: SIP/2. 0/UDP mgcf 1 .homel .net;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip : icscf 1 . homel . net ; lr> 

P-Asserted-Identity: <tel: +l-212-555-2222> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=home2 .net 

Privacy: none 

From: <tel: +l-212-555-2222>; tag=171828 

To: <tel:+l-212-555-6666> 

Call -ID: f81d4fae-7dec-lld0-a765-0 0a0c91e6bf6 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

Cseq: 127 INVITE 

Supported: 10 Orel, precondition 

Contact : <sip :mgcf 1 .homel .net>; +g. 3gpp . icsi -ref="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 



Request-URI: UAI PSI DN as received in the SETUP message. 

P-Asserted-Identity: The MGCF inserts the tel-URI containing the subscriber number, as received from the 
ICS UE B. 

SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

15. SIP 100 (Trying) response (intermediate IM CN subsystem entities to MSC Server not enhanced for ICS) 
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The intermediate IM CN subsystem entities respond to the MSC Server not enhanced for ICS with a SIP 100 
(Trying) response. There is no ICS specific content in this response. 

16. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) - see example in Table A.5.4-16 

The SIP INVITE request is sent to the SCC AS. 

Table A.5.4-16: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 



INVITE tel:+l-212-555-6666 SIP/2.0 

Via: SIP/2 .0/UDP scscf2 .home2 .net ;branch=z9hG4bK332b33 .1, SIP/2 .0/UDP 

icscf 1 .homel .net ;branch=z9hG4bK8 71yl2 .1, SIP/2 . 0/UDP mgcf 1 .homel .net ;branch=z9hG4bKnashds7 
Max- Forwards : 68 
Route : <sip:sccas .homel .net;lr>, <sip:scscfl .homel .net; lr>;orig-dialog- 

id="yuf lsae80r3rb3fh31ondyr82 9cnyr3 81cn93 2YDWref 0w0-wwtg3 74" 
Record-Route : <sip : scscf 1 . homel . net ; lr> 
P-Asserted- Identity : 
P-Charging-Vector : 
Privacy: 
From: 
To: 

Accept -Contact : 
Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o=- 



17. SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There is 
no ICS specific content in this response. 

18. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in Table A.5.4- 
18 

The SCC AS responds to the SIP INVITE request with a SIP 200 (OK) response that includes an SDP answer. 
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Table A.5.4-18: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2 .0/UDP scscf2 .home2 .net ;branch=z9hG4bK332b33 .1, SIP/2 .0/UDP 

icscf 2 .home2 .net ;branch=z9hG4bK8 71yl2 .1, SIP/2 . 0/UDP mgcf 2 .home2 .net ;branch=z9hG4bKnashds7 

Record-Route : <sip : sccas . homel . net ; lr> , <sip : scscf 2 . home2 . net ; lr> 

P-Access-Network-Info : 

Privacy: none 

From: <tel: +l-212-555-2222>; tag=171828 

To: <tel: +1-212 -555- 6666 >;tag=1667452 

Call -ID: f81d4fae-7dec-lld0-a765-0 0a0c91e6bf6 

CSeq: 

Require: 10 Orel, precondition 

Contact : <sip :userl_publicl®home2 .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel"> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933623 2987933623 IN IP6 5555 : : ggg : f f f : aaa : bbb 

s = - 

c = IN IP6 5555 : :ggg:fff :aaa:bbb 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrcv 

a=curr:qos remote sendrcv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=maxptime : 20 



19. SIP 200 (OK) response (intermediate IM CN subsystem to MGCF) 

The intermediate IM CN subsystem entities route the SIP 200 (OK) response to the MSC Server not enhanced 
for ICS. 

20. ISUP ANM message (MGCF to MSC Server not enhanced for ICS) 

On receipt of the SIP 200 (OK) response, the MGCF generates an ISUP ANM message and sends this to the 
MSC Server not enhanced for ICS. 

There is no ICS specific content in this message. 

21-22. These steps are identical to steps 19-20 described in subclause A. 5. 3. 

23-24. SIP ACK request (MGCF to SCC AS via intermediate IM CN subsystem entities) 

On receipt of the SIP 200 (OK) response, the MGCF sends a SIP ACK request which is routed to the SCC AS 
via the intermediate IM CN subsystem entities. There is no ICS specific content in this response. 

25-36. These steps are identical to steps 23-34 described in subclause A. 5. 3. 

A. 5. 5 Signalling flows for termination to an ICS UE with CS media 
using Gm reference point when using an MSC Server 
enhanced for ICS and UE assisted T-ADS 

Figure A.5.5-1 shows the termination of a call to an ICS UE using CS bearers controlled through the IM CN subsystem. 
In this example the MSC Server is enhanced for ICS and is capable of translating NAS signalling received from the ICS 
UE to SIP and vice versa. In this example, the UE supports UE assisted terminating access domain selection. 
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Figure A.5.5-1 : ICS UE termination withi CS media using Gm reference point whien using an lUISC 

Server enhianced for ICS - UE assisted T-ADS 

The details of the signalling flows are as follows: 

1-5: These steps are identical to steps 1-5 described in subclause A.5.3. 
The SDP shows that local preconditions on the originating side are met. 

6. Terminating Access Domain Selection 

The sec AS performs initial T-ADS selecting IMS for the service control signalling when UE-B is registered in 
the IMS. 

7. SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in Table A.5.5-7. 

The SCC AS, acting as a routing B2BUA, generates a SIP INVITE request based upon the received SIP INVITE 
request and sends it to the intermediate subsystem entities. 

Table A.5.5-7: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip:user2_publicl®homel .net SIP/2.0 

Via: SIP/2. 0/UDP sccas .homel .net;branch=z9hG4bKnas34r5 

Max- Forwards : 65 

Route : <sip:cb03aOs09a2sdfglkj490333@scscf 1 .homel .net ; lr>;orig-dialog-id="0 : 73935718_92S45110- 

712 7 86jd24 63 953 02d-zKE" 
Record-Route : <sccas . homel . net ; lr> 
P-Access-Network-Info : 
P-Asserted- Identity : 
P- Charging- Function-Addresses : ccf=[5555::b99:c88:d77:e66]; ccf= [5555 : : a55 :b44 : c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
P-Charging-Vector : 
P-Asserted-Service : 

Accept -Contact : * ; +g. 3gpp . icsi-ref = "urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
Accept -Contact : * ; +g. 3gpp . ics= "principal" /explicit /require 
Privacy: 

From: <sip :user2_publicl@home2 .net>; tag=17182 8 
To: 

Call-ID: 
Cseq: 

Supported: 
Accept : 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v=0 

0=2987933615 2987933615 IN IP6 5555 : : eee : ccc : aaa :bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=audio 49170 RTP/AVP 97 3 98 

a=creq:med-vO , ccap-vO 

a=mcap:l 97 

a=mcap:2 GSM/80 00/1 

a=mcap:3 98 

a=mcap:4 - 

a=tcap : 1 RTP/AVP RTP/AVPF PSTN 

a=ccap:l IN IP6 5555 :: eee : fff : aaa :bbb 

a=ccap:2 PSTN E164 +12125556666 

a=acap:l setup : actpass 

a=acap:2 connection: new 

a=acap:3 rtpmap:97 AMR 

a=acap:4 fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=acap:5 rtpmap:98 telephone-event 

a=pcfg:l t=l m=l,2,3 c=l a=3,4,5 

a=pcfg:2 t=2 m=l,2,3 c=l a=3,4,5 

a=pcfg:3 t=3 m=4 c=2 a=l,2 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos optional remote sendrecv 
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8. SIP 100 (Trying) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities respond to the SCC AS with a SIP 100 (Trying) response. There is 
no ICS specific content in this response. 

9. SIP INVITE request (intermediate IM CN subsystem entities to ICS UE B) 

The SIP INVITE request is routed towards the called party ICS UE B since further iFC evaluation is not 
necessary. 

10. SIP 100 (Trying) response (ICS UE B to intermediate IM CN subsystem entities) 

The ICS UE B responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There 
is no ICS specific content in this response. 

1 1 . Terminating Access Domain Selection 

The ICS UE performs T-ADS. In this example the UE chooses a CS bearer for media 

12 SIP 183 (Session Progress) response (ICS UE to intermediate IM CN subsystem entities) - see example in 
table A.5.5-12 

The ISC UE generates a SIP 183 (Session Progress) response based upon the received SIP INVITE request and 
indicates in the SDP that the CS media bearer is used. 

Table A.5.5-12: SIP 183 (Session Progress) response (IMS UE to intermediate IM CN subsystem 

entities) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 1 . homel . net ;branch=z9hG4bK240f 34 . 1 , 

SIP/2 .0/UDP scscfl. homel. net ;branch=z9hG4bK332b23 .1, 

SIP/2. 0/UDP sccas .homel .net, •branch=z9hG4bKnas34r5, 

Record-Route : <sip :pcscf 1 . homel . net ; Ir ; <sip : scscfl . homel . net ; lr> ; <sip : sccas . homel . net ; lr> 

P-Access -Network- Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=2 34151D0FCEll 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" 

Privacy: none 

From: <sip :user2_publicl®home2 .net>; tag=17182 8 

To: <tel: +1-212 -555 -2222 >;tag=17182 

Call-ID: 

CSeq: 

Require: lOOrel 

Contact : <sip :userl_publicl®homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

0=2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = 

t = 

m=audio - PSTN - 

c=PSTN - - 

a=acfg: 3 

a=setup : active 

a=connection : new 

a=corr-id:2890W284hAT452612908awudf jang908 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 



14. SETUP message (ICS UE B to MSC Server enhanced for ICS) 

The ICS UE B inititates bearer setup in the CS domain by sending a SETUP message to the MSC Server 
enhanced for ICS. 

Specifically for this signalling flow, the SETUP message includes: 
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Called Party Number information element = = [(Numbering plan identifier = ISDN/telephony numbering 
plan), (type of number = international number ), (Number digits = 12 12556666)]. The Called Party Number 
information element is set to the lUA PSI DN. 

Bearer Capability information element = [(information transfer capability = speech), (speech versions = FR 
AMR, GSM EFR, GSM PR)] 

- Supported Codec List information element = { [(SysID 1 = UMTS), (Codec Bitmap for SysID 1 = UMTS 
AMR 2)], [(SysID 2 = GSM), (Codec Bitmap for SysID 2 = FR AMR, GSM EFR, GSM FR)] } 

The MSC Server enhanced for ICS knows the calling party number corresponding to the ICS UE B. 

15. CALL PROCEEDING message (MSC Server enhanced for ICS to ICS UE B) 

Upon receipt of the SETUP message from the ICS UE B, the MSC Server enhanced for ICS responds with a 
CALL PROCEEDING message. There is no ICS specific content in this message. 

16. SIP PRACK request (SCC AS to IM CN subsystem entities) 

sec AS acknowledges the receipt of 183 (Session Progress) response. 

16. SIP PRACK request and SIP 200 (OK) response 

The SCC AS sends a SIP PRACK request towards the ICS UE via the intermediate IM CN subsystem entities as 
a result of receiving the reliably sent SIP 183 (Session Progress) response containing the SDP answer. 

Upon receipt of the SIP PRACK request, the ICS UE responds with a SIP 200 (OK) response towards the SCC 
AS via the intermediate IM CN subsystem entities. 

The is no ICS specific content in these SIP messages. 

17. SIP INVITE request (MSC Server enhanced for ICS to intermediate IM CN subsystem entities) - see 
example in A.5.5-17. 

The MSC Server enhanced for ICS maps the received SETUP message to a SIP INVITE request which is routed 
towards the intermediate IM CN subsystem entities. The INVITE request is addressed to the lUA PSI DN in the 
Request-URI. 
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Table A.5.5-17: SIP INVITE request (MSC Server enhanced for ICS to intermediate IM CN subsystem 

entities) 



INVITE tel:+l-212-555-6666 SIP/2.0 

Via: SIP/2. 0/UDP msc2 .homel .net;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route: <sip : icscf 2 .homel .net : lr> 

P-Asserted-Identity: <tel: +l-212-555-2222> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=home2 .net 

P-Access-Network-Info : 

Privacy: none 

Accept -Contact : * ; +g. 3gpp . icsi-ref = "urn%3Aurn- 7% 3gpp- service . ims . icsi .mmtel" 

From: <sip :user2_publicl@homel .net>; tag=276859 

To: <tel:+l-212-555-SSSS> 

Call -ID: f81d4fae-7dec-lldO-a765-OOaOc91e6bfS 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, 199 

Contact : <sip :user2_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- 
service . ims .icsi .mmtel" ; +g. 3gpp. ics=" server" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : f f f 

s = 

c = IN IP6 5555 : :aaa:bbb:ccc:fff 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



Request-URI: UAI PSI DN as received in the SETUP message. 

P-Asserted-Identity: The MSC Server enhanced for ICS inserts the tel-URI containing the subscriber 
number, as received from the ICS UE B. 

Accept-Contact: The MSC Server enhanced for ICS includes the mmtel feature tag in the INVITE request . 

Contact: The MSC Server enhanced for ICS includes the GRUU received at registration, the media feature tag 
g.3gpp. icsi-ref set to "urn%3Aurn-7%3gpp-service. ims. icsi. mmtel" and the media feature tag g.3gpp.ics set to 
"server". 

SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

18. SIP 100 (Trying) response (intermediate IM CN subsystem entities to MSC Server enhanced for ICS) 

The intermediate IM CN subsystem entities respond to the MSC Server enhanced for ICS with a SIP 100 
(Trying) response. There is no ICS specific content in this response. 

19. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) - see example in Table A.5.5-19 

The SIP INVITE request is sent to the SCC AS. 
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Table A.5.5-19: SIP INVITE request (intermediate IIUI CN subsystem entities to SCC AS) 



INVITE tel:+l-212-555-6666 SIP/2.0 

Via: SIP/2 .0/UDP scscf2 . home 2 .net ;branch=z9hG4bK3 3 2b3 3 . 1, SIP/2 . 0/UDP 

icscf 1 .homel .net ;branch=z9hG4bK871yl2 . 1, SIP/2 . 0/UDP msc2 .homel .net ;branch=z9hG4bKnashds7 
Max-Forwards: 68 
Route : <sip : sccas .homel .net :lr>, <sip:scscfl .homel .net; lr>;orig-dialog- 

id="yuf lsae80r3rb3fh31ondyr82 9cnyr3 81cn93 2YDWref 0w0-wwtg3 74" 
Record-Route : <sip : scscf 1 . homel . net ; lr> 
P-Asserted- Identity : 
P-Charging-Vector : 
P-Access-Network-Info : 
Privacy: 
From: 
To: 

Call-ID: 
Accept-Contact : 
Cseq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 



20. SIP 100 (Trying) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. There is 
no ICS specific content in this response. 

21. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.5.5- 
21. 

The SCC AS responds to the SIP INVITE request with a SIP 200 (OK) response that includes an SDP answer. 
The SDP shows local preconditions as received in the SIP INVITE request in step 4. 
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Table A.5.5-21 : SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2 .0/UDP scscfl.homel.net;branch=z9hG4bK332b33 .1, SIP/2 .0/UDP 

icscf 1 .homel .net ;branch=z9hG4bK871yl2 . 1, SIP/2 . 0/UDP msc2 .homel .net ;branch=z9hG4bKnashds7 

Record-Route : <sip : sccas . homel . net ; lr> , <sip : scscf 1 . homel . net ; lr> 

P-Access-Network-Inf o : 

Privacy: none 

From: <tel: +l-212-555-2222>; tag=276859 

To: <tel: +1-212 -555- 6666 >;tag=347529 

Call -ID: f81d4fae-7dec-lld0-a765-0 0a0c91e6bf6 

CSeq: 

Require: 10 Orel, precondition 

Contact : <sip:userl_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99- 
ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel"> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933623 2987933623 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: ccc : ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrcv 

a=curr:qos remote sendrcv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=maxptime : 20 



22. SIP 200 (OK) response (intermediate IM CN subsystem to MSC Server enhanced for ICS) 

The intermediate IM CN subsystem entities route the SIP 200 (OK) response to the MSC Server enhanced for 
ICS. 

23. CONNECT message (MSC Server enhanced for ICS to ICS UE B) 

The enhance MSC Server maps the received SIP 200 (OK) response to a CONNECT message. There is no ICS 
specific content in this message. 

24. CONNECT ACKNOWLEDGEMENT message (ICS UE B to MSC Server enhanced for ICS) 

The ICS UE A sends a CONNECT ACKNOWLEDGMENT message upon receiving the CONNECT message. 
There is no ICS specific content in this message. 

25-26. SIP ACK request (MSC Server enhanced for ICS to SCC AS via intermediate IM CN subsystem 
entities) 

The MSC Server enhanced for ICS interworks the received CONNECT ACKNOWLEDGEMENT message to a 
SIP ACK request which is routed to the SCC AS via the intermediate IM CN subsystem entities. There is no ICS 
specific content in this response. 

27-28. SIP 180 (Ringing) response (ICS UE B to SCC AS via intermediate IM CN subsystem entities) 

The ICS UE B responds to the received SIP INVITE request with a SIP 180 (Ringing) response. The response 
contains no SDP body and contains no ICS specific content. The SIP 180 (Ringing) response is routed to the 
SCC AS. 

29-30. SIP 180 (Ringing) response (SCC AS to originating IM CN subsystem via intermediate IM CN 
subsystem entities) 

The SCC AS routes the received SIP 180 (Ringing) response towards the originating network and the calling 
party. 

31. SIP 200 (OK) response (ICS UE B to intermediate IM CN subsystem entities) - see example in Table 

A.5.5-27 
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The ICS UE B responds to the received initial SIP INVITE request with a SIP 200 (OK) response. This SIP 200 
(OK) does not induce an SDP body. 

32. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The SIP 200 (OK) response from the ICS UE is routed towards the SCC AS. 

33-34. SIP 200 (OK) response (SCC AS to originating IM CN subsystem via intermediate IM CN subsystem 
entities) 

The SIP 200 (OK) response is routed towards the originator of the session in the originating IM CN subsystem. 
This SIP 200 (OK) response includes an SDP answer the correponds to the SDP received from the MSC server 
enhaced for ICS and indicates that local preconditions are met. 

Table A.5.5-33: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2 .0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b33 .1, SIP/2 . 0/UDP 
icscf 1 .homel .net;branch=z9hG4bK871yl2 .1, SIP/2 . 0/UDP 
scscf l.home2 .net ;branch=z9hG4bK3 3 2b2 3 .1, SIP/2. 0/UDP 
pcscf l.visited2 .net ;branch=z9hG4bK431h2 3 .1, SIP/2 .0/UDP 
[5555 : :aaa:bbb: ccc :ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record-Route: <sip :pcscf 1 . visitedl .net ; lr>, <sip : scscf 1 .homel .net ; lr>, <sccas .homelnet ; lr> 

P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <tel: +l-212-555-llll>; tag=171828 

To: <tel: +1-212 -555 -2222 >;tag=684213 

Call -ID: Cb03a0s0 9a2sdfglkj 490333 

CSeq: 

Require: lOOrel, precondition 

Contact : <sip :user2_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf G>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933623 2987933623 IN IP6 5555 :: aaa : bbb : ccc : eee 

s = - 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t=0 

m=audio 3456 RTP/AVP 97 96 

a=curr:qos local sendrcv 

a=curr:qos remote sendrcv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=maxptime : 20 



35-36. SIP ACK request (originating IM CN subsystem to SCC AS via intermediate IM CN subsystem 
entities and SCC AS) 

The originating IM CN subsystem sends a SIP ACK request to the SCC AS via the intermediate IM CN 
subsystem entities. There is no ICS specific content in this response. 

37-38. SIP ACK request (SCC AS to ICS UE B via intermediate IM CN subsystem entities and SCC AS) 

The SCC AS sends a SIP ACK request to the ICS UE B via the intermediate IM CN subsystem entities. There is 
no ICS specific content in this response. 
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A. 6 Signalling flows for supplementary service invocation 
for ICS 

A. 6.1 Communication Hold/Resume with Announcement 

Figure A.6.1-1 provides the example flow for ICS Communication Hold/Resume with Announcement over Gm 
reference point for the ICS UE. The SCC AS shown together with MRF is for the purpose of simplifying the signalling 
flow. 
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Figure A.6.1-1 : ICS Communication Hold/Resume with Announcement over Gm reference point 
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The details of the signalhng flows are as follows: 

1 . Session establishment 

It is assumed that as a result of ICS UE origination procedure defined in subclause A.4.2 .ICS UE A establish a 
multimedia session with UE B. 

2. SIP re-INVITE request (ICS UE A to intermediate IM CN subsystem entities) - see example in 
table A.6.1-2. 

UE-A sends a re- INVITE request to UE-B to hold the session. Hold is done by changing the SDP attribute: 

"a=sendonly", if the stream was previously a sendrecv media stream; 

"a=inactive", if the stream was previously a recvonly media stream. 

Table A.6.1-2: SIP re-INVITE request (ICS UE A to intermediate IM CN subsystem entities) 



INVITE sip:userl_publicl@home2 .net ;gr=urn:uuid: 2ad8 950e-4 8a5-4a74-8d99-ad76cc7f c74> SIP/2 . 

Via: SIP/2. 0/UDP [4444 : : ccc :ddd: ccc : eee] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds8 

Max-Forwards: 70 

Route : <sip :pcscf 1 .homel .net; lr;comp=sigcomp>, <sip :orig®scscf 1 .homel .net ; lr>, 
<sccas .homel .net> 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=17182 9 

To: <tel:+l-212-555-2222>; tag=184483 

Call -ID: cb03a0s0 9a2sdfgKlkj4 90334 

Cseq: 127 INVITE 

Contact : <sip :user2_publicl®homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal "> 

Content-Type: application/sdp 

Content-Length: (...) 



Editor" s Note: The SDP in this SIP INVITE request needs to be specified. 

3. SIP re-INVITE request (intermediate IM CN subsystem entities to SCC AS ) 

The intermediate IM CN subsystem entities forwards the re-INVITE request to SCC ASATAS based upon initial 
filter criterion. 

4-5. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)- see example in 
table A.6.1-4. 

SCC AS will generate the re-INVITE request containing IMS media and forward it towards UE B. The 
MGW-SDP is obtained during ICS UE A originating procedure.. 
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Table A.6.1-4: SIP re-INVITE request (SCC AS/TAS to intermediate IM CN subsystem entities) 



INVITE sip:userl_publicl®home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74> SIP/2 . 

Via: SIP/2 .0/UDP sccas . homel . net ;branch=zlhG4bKnashds8 ; SIP/2 .0/UDP 
[4444 : :ccc : ddd : ccc :eee] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds8 

Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 

Privacy: none 

From: <sip :user2_publicl®homel .net>; tag=276859 

To: <tel:+l-212-555-2222>;tag=34 752 9 

Call -ID: cb03a0s09a2sdfgKlkj 490334 

Cseq: 127 INVITE 

Contact : <sip :user2_publicl®homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555:: adf : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: adf : bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a=rtpmap:96 telephone -event 

a=sendonly 



6. The UE B acknowledge the re-INVITE request with 200 (OK) response to S-CSCF with recvonly 
attribute- see example in table A.6.1-6 

Table A.6.1-6: 200 (OK) response (UE B to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2 .0/UDP scscfl. homel. net ;branch=zlhG4bKnashds8; SIP/2 . 0/UDP 
sccasOhomel .net ;branch=zlhG4bKnashdsB ; SIP/2 . 0/UDP 
[5555 : :eee:f f f :aaa:bbb] : 8 8 05 ; comp=sigcomp;branch=z9hG4bK2 3dh4 2 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Contact : <sip:userl_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74> 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 3333 :: ccc : ddd : ccc : eee 

s = - 

c=IN IP6 3333 :: ccc :ddd: ccc : eee 

t=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a=rtpmap:96 telephone -event 

a=recvonly 



7. SIP 200 (OK) response 

The intermediate IM CN subsystem entities forward the 200 (OK) response to SCC AS according to standard 
IMS procedure. 

After the SCC AS receive the 200 (OK) response, it will indicate MRF to play Announcement to UE-B in 
order to indicate Communication HOLD. 

8. SIP UPDATE request (SCC AS/TAS/MRF to intermediate IM CN subsystem entities) - see example in 
table A.6.1-8 

The SCC AS generates SIP UPDATE request with SDP offer obtained from MRF in order to negotiate the 
media with inactive attribute. 
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Table A.6.1-8: UPDATE request (SCC AS to IM CN subsystem entities) 



UPDATE sipimgcfohomel .net SIP/2.0 

Via: SIP/2. 0/UDP sccas . homel . net ;branch=z9hG4bKnashdsb 

Max-Forwards: 70 

Route : <sip : scscf 1 . homel . net ; lr> 

From: <tel:+l-212-555-lll>;tag=17182 8 

To: <sip:+3 58-50-4 8214 3 7@homel . net ;user=phone> ; tag=31415 9 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 12 9 UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 3333 : : ccc : ddd : ccc : eee 

s = - 

c=IN IP6 3333 :: ccc :ddd: ccc : eee 

t=0 

m=audio 3466 RTP/AVP 97 96 

b=AS:25 .4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 

a=inactive 



NOTE: /Uternatively, unspecified connection address and/or zero bandwidth in SDP in step 4 and step 8 could be 
used in order to control RTCP and RTP data between the MGCF and UE-B. 

9. SIP UPDATE request 

The intermediate IM CN subsystem entities forward the UPDATE request to MGCF according to standard 
IMS procedure. 

10-11. SIP 200 (OK) response (MGCF to SCC AS) 

In response to the SIP UPDATE request a SIP 200 (OK) response is sent from MGCF to SCC AS. 
12-13. SIP 200 (OK) response 

The SCC AS will send a SIP 200 (OK) response to ICS UE A according to normal IMS procedure. 
Editor" s Note: The SDP in this SIP 200 (OK) response needs to be specified. 
14-17. ACK request 

The SIP ACK request is sent from the ICS UE A to UE B according to standard IMS procedure. 

18. SIP re-INVITE request (ICS UE A to intermediate IM CN subsystem entities) - see example in 
table A.6.1-18. 

UE A sends a SIP re-INVITE request to UE B to resume the session. Resume is done by changing the SDP 
attribute: 

Table A.6.1-18: SIP re-INVITE request (ICS UE A to intermediate IM CN subsystem entities) 



INVITE sip:Userl_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f C74SIP/2 . 

Via: SIP/2. 0/UDP [4444 : :ccc :ddd:ccc :eee] : 1357;comp=sigcomp;branch=z9hG4bKnashds8 

Max-Forwards: 68 

Route : <sip :pcscf 1 .homel .net; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net; lr>, 
<sccas .homel .net ; lr> 

Privacy: none 

From: <tel: +1-212 -555 -2222 >;tag=171829 

To: <sip: +358-50-4821437@homel . net ;user=phone> ; tag=1844 83 

Call -ID: cb0 3a0s0 9a2sdfgKlkj4 90 3 34 

Cseq: 127 INVITE 

Contact : <sip :user2_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal "> 

Content-Type: application/sdp 

Content-Length: (...) 
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Editor" s Note: The SDP in this SIP INVITE request needs to be specified. 

19. SIP re-INVITE request 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to SCC AS according to 
standard IMS procedure. 

As SCC AS receives the SIP re-INVITE request, it will indicate MRF to stop Announcement. 

20. SIP re-INVITE request (SCC AS to Intermediate IM CN subsystem entities) - see example in table 
A,6,l-20. 

In order to re-connect the CS bearer and IMS bearer, SCC AS will generate the SIP re-INVITE request 
towards MGCF with no SDP according to standard 3PCC procedure. 

Table A.6.1-20: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sipimgcfohomel .net SIP/2.0 

Via: SIP/2. 0/UDP sccas . homel . net ;branch=z9hG4bKnashdsb 
Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 
Privacy: none 

From: <tel:+123456>;tag=171829 
To : <sip : user2_publicl@homel . net> ; tag=184483 
Call -ID: cb0 3a0s0 9a2sdfgKlkj4 90 3 34 
Cseq: 127 INVITE 

Contact : <sip:userl_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99- 
ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Content-Length : 



21. SIP re-INVITE request 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to MGCF according to 
standard IMS procedure. 

22. The MGCF acknowledge the re-INVITE request with SIP 200 (OK) to ICS UE A with sendrecv 
attribute- see example in table A.6.1-22 

Table A.6.1-22: SIP 200 (OK) response (MGCF to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl . homel . net ;branch=z9hG4bK23436s . 1 , SIP/2. 0/UDP 

sccas. homel. net ;branch=z9hG4bK23d244 .1, SIP/2 .0/UDP 
Privacy: none 
From: 
To: 

Call-ID: 
Cseq: 

Contact : <sip :mgcf®homel .net>; +g. 3gpp . icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 
Content-Type : application/SDP 
Content-Length: (...) 
v=0 

o=- 2987933615 2987933615 IN IP6 5555:: adf :bbb : ccc : ddd 
s = - 

c=IN IP6 5555 :: adf :bbb: CCC: ddd 
t = 

m=audio 3456 RTP/AVP 97 96 
b=AS:25 .4 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; maxframes=2 
a=rtpmap:96 telephone-event 
a=sendrecv 



NOTE: It is assumed that MGCF will respond to the SIP re-INVITE request with the SDP offer containing 
"sendrecv" attribute. 

23. 200 (OK) response 
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The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to SCC AS according to 
standard IMS procedure. 

24. SIP re-INVITE request (SCC AS to Intermediate IM CN subsystem entities) - see example in table 
A.6.1-24. 

SCC AS generates a SIP re-INVITE request containing the SDP offer from MOW and forward it to UE B. 
Table A.6.1-24: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip:Userl_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2 . 
Via: SIP/2. 0/UDP sccas .homel .net;branch=z9hG4bKnashds3 
Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 
Privacy: none 

From: <tel:+123456>;tag=171829 
To: <tel:+l-212-555-2222>;tag=1844 8 3 
Call -ID: cb03a0s09a2sdfgKlkj 490334 
Cseq: 127 INVITE 

Contact : <sip :user2_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Content-Length: (...) 
v=0 

o=- 2987933615 2987933615 IN IP6 5555:: adf :bbb : ccc : ddd 
s = - 

c=IN IP6 5555 :: adf :bbb: CCC: ddd 
t = 

m=audio 3456 RTP/AVP 97 96 
b=AS:2 5.4 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2 , 5, 7; maxframes=2 
a=rtpmap:96 telephone-event 
a=sendrecv 



25 . SIP Re-INVITE request 

The intermediate IM CN subsystem entities forward the Re-INVITE request to UE B according to standard 
IMS procedure. 

26. The UE B acknowledge the Re-INVITE request with 200 OK to ICS UE A with sendrecv attribute- see 
example in table A.6.1-26 

Table A.6.1-26: 200 (OK) response (UE B to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl . homel . net ;branch=zlhG4bK23436s . 1 

SIP/2 .0/UDP scscfl. homel. net ;branch=z9hG4bK23436s.l, SIP/2 .0/UDP 

sccas .homel .net ;branch=z9jG4bK23d244 . 1, 
P-Access-Network-Info : 

P- Charging- Vector: icid-value="AyretyU0dm+602IrT5tAFrbHLso=3 23 5 51024" 
From: 
To: 

Call-ID: 
CSeq: 

Contact : < sip: user l_publicl@home2 .net ;gr=urn:uuid: 2ad8950e-4 8a5-4a74-8d99- 
ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 
Content-Length: (...) 
v=0 

o=- 2987933615 2987933615 IN IP6 3333 :: ccc : ddd : ccc : eee 
s = - 

c=IN IP6 3333 :: ccc :ddd: ccc : eee 
t = 

m=audio 3456 RTP/AVP 97 96 
b=AS:25 .4 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 
a=rtpmap:96 telephone -event 
a=sendrecv 



27. 200 (OK) response 
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The intermediate IM CN subsystem entities forward the 200 OK response to SCC AS according to standard 
IMS procedure. 

28-29. The SCC AS acknowledge the 200 OK from MGCF with ACK request 

SCC AS send ACK request with the SDP answer from UE B to MGCF according to standard IMS procedure. 
30-31. 200 OK response 

SCC AS send 200 OK response to UE A according to standard IMS procedure. 
32-33. ACK request 

UE A acknowledge the 200 OK response with ACK request according to standard IMS procedure. 

34-35. ACK request 

The SIP ACK request is sent from the SCC AS to UE B according to standard IMS procedure thus 
completing session RESUME procedure. 

A. 6. 2 Explicit Communication Transfer using Gm reference point, 
ICS UE as transfer recipient 

Figure A.6.2-1 describes how IMS consultative ECT is perftirmed when ICS UE is playing the role of transfer recipient 
using Gm reference point. The UE A has a held call with UE C and a held call with ICS UE B before transfer. 
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Figure A.6.2-1 : IMS Consultative ECT via Gm for ICS UE (transfer recipient) 

The details of the signalhng flows are as follows: 



£75/ 



3GPP TS 24.292 version 8.4.0 Release 8 1 28 ETSI TS 1 24 292 V8.4.0 (201 0-01 ) 

1 . Session establishment and Communication HOLD 

It is assumed that as a result of ICS UE origination procedure defined in subclause A.4.2 , ICS UE B establish a 
multimedia session with UE A and session between UE A and UE C on HOLD according to the procedure 
specified in subclause A.6.L 

2. SIP REFER request (UE A to intermediate IM CN subsystem entities) - see example in table A.6.2-2. 

UE A initiates transfer of ICS UE B to UE C by sending a REFER request to ICS UE B as specified in 
3GPPTS 24.173 [9] 

It contains following parameters. 

Request-URI: contains the public user identity of ICS UE B. 

Refer-To: contains the GRUU of UE C. 

Referred-By: contains the public user identity of the referring user. As in this example, the referring user UE A 
has decided to indicate its own identity to the referred user. 

Table A.6.2-2: SIP REFER request (UE A to intermediate IM CN subsystem entities) 



REFER sip: icsueb_publicl@homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc:ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :uea_publicl@homel .net> 

Privacy: none 

From: <sip :uea_publicl@homel .net>; tag=171828 

To: <sip: icsueb publiciohomel .net > 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90 3 33 

Cseq: 127 REFER 

Refer- To : <sip :uec_publicl@homel .net ;gr=urn:uuid: e76 3c4acb-8-may-12bl-cG78- 

12blc88c6fa2;method=INVITE>?Replaces=cb03a0s09a2sdfhlij490444;from-tag=165343;to- 

taq=236717&Require=replaces 
Referred-By: <sip :userl_publicl@homel .net > 
Contact < sip :usea_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6>;+ 

g. 3gpp. ics="principal">; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Content-Length : 



3. SIP REFER request (intermediate IM CN subsystem entities to SCC AS) - see example in table A.6.2-3 

The intermediate IM CN subsystem entities forward the REFER request to SCC AS via Transferor AS, the 
Transferor AS will change the Refer-To header field value to ECT Session Identifier that is shown as private- 
URI in the flow, according to 3GPP TS 24.629 [19]. 

Table A.6.2-3: SIP REFER request (intermediate IM CN subsystem entities to SCC AS) 



REFER sip: icsueb_publicl@homel .net SIP/2.0 

Via: SIP/2 .0/UDP scscfl . homel . net ;branch=z9pG4bK392b23 .1, SIP/2 . 0/UDP 
ectas.homel.net;branch=z9hG3bK3 82b2 3 .1, SIP/2 .0/UDP 
scscfl .homel .net ;branch=z9pG4bK3 92b2 5 . 1 , SIP/2 . 0/UDP 
pcscfl .homel .net ;branch=z9aK4bK2 92b2 . 3 , SIP/2 . 0/UDP 
[5555 : :aaa:bbb: ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 66 

Route: <sip : sccas .homel .net ; lr> 

P-Asserted-Identity : "John Doe" <sip :uea_publicl@homel .net> 

Privacy: 

From: 

To: <sip: icsueb publiciohomel .net >; tag=26876 

Call-ID: 

Cseq: 

Refer- To : <sip : 12 34 5@ectas .homel .net> 

Referred-By: 

Contact : 

Content-Length : 



4-5 . SIP REFER request 
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The sec AS forwards the REFER request to ICS UE B according to normal IMS procedure. 

6. SIP 202 (Accepted) response (ICS UE B to intermediate IM CN subsystem entities) - see example in 
table A.6.2-6 

Table A.6.2-6: SIP 202 (Accepted) response (ICS UE B to intermediate IM CN subsystem entities) 



SIP/2.0 202 Accepted 

Via: SIP/2 .0/UDP pcscf2 . homel . net ;branch=z9aK4bK292b2x . 3 , SIP/2 .0/UDP 

scscf 1 .homel .net ;branch=z9pG4bK3 92b2 3 . 1 , SIP/2 . 0/UDP ectas .homel .net ;branch=z9hG3bK3 82b2 3 . 1 , 

SIP/2 .0/UDP scscf 1. homel. net ;branch=z9pG4bK3 92b2 5.1, SIP/2 .0/UDP 

pcscfl .homel .net ;branch=z9aK4bK2 92b2 . 3 , SIP/2 . 0/UDP 
[5555 : :aaa:bbb: ccc :ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Privacy: 
From: 

To: To: <sip: icsueb publiciohomel .net >; tag=26876 
Call-ID: 
CSeq: 
Contact : <sip : icsueb_publicl@homel .net ;gr=urn:uuid: 2ad8950e-4 8a5-4a74-8d99- 

ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Content-Length : 



7-9. SIP 202 (Accepted) response 

The intermediate IM CN subsystem entities forward the SIP 202 (Accepted) response to UE A according to 
normal IMS procedure 

10. SIP INVITE request (ICS UE B to intermediate IM CN subsystem entities) - see example in table A.6.2- 
10. 

The ICS UE B initiates session establishment towards private-URI set in the Refer-To header field by initiating 
an INVITE request. 

Table A.6.2-10: SIP INVITE request (ICS UE B to intermediate IM CN subsystem entities) 



INVITE sip: 12345@ectas.homel.net SIP/2.0 

Via: SIP/2. 0/UDP [3333 : :ccc :ddd:ccc :eee] : 1357 ; comp=sigcomp;branch=z9hG4bKnashdse 
Max- Forwards : 70 

Route : <sip :pcscf 2 .homel .net; lr;comp=sigcomp>, <sip : origSscscf 1 .homel .net ; lr> 
P-Preferred-Identity: <tel: +l-212-555-llll> 
Privacy: none 

From: <sip : icsueb_publicl@homel .net>; tag=276589 
To: <sip : 12345®ectas .homel .net> 
Call -ID: cb0 3a0s0 9a2sdfgKlkj4 90 3 34 
Cseq: 127 INVITE 

Contact : <sip : icsueb_publicl@homel .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99- 
ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 



Editor" s Note: The SDP in this SIP INVITE request needs to be specified. 

1 1. SIP 100 (Trying) response (intermediate IM CN subsystem entities to ICS UE B) 

The intermediate IM CN subsystem entities respond to the ICS UE B with a SIP 100 (Trying) response 

There is no ICS specific content in this response. 

12-13. SIP INVITE request / SIP 100 (Trying) response 

The intermediate IM CN subsystem entities forward the SIP INVITE request to SCC AS and SCC AS respond 
with SIP 100 (Trying) response according to normal IMS procedure. 

14. SIP re-INVITE (SCC AS to intermediate IM CN subsystem entities) - see example in table A.6.2-14 

SCC AS initiates SIP re-INVITE request containing no SDP and sends it towards the MGCF according to 
standard 3PCC procedure. 
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Table A.6.2-14: SIP re-INVITE request (SCC AS to intermediate IIVI CN subsystem entities) 



INVITE sip :mgcf ©home 1 .net SIP/2.0 

Via: SIP/2. 0/UDP sccas . homel . net ;branch=z9hG4bKnashdsb 

Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : <sip :uea@homel .net> 

Privacy: none 

From: <tel: +1-212- 555 -llll>;tag=171838 

To : <sip : icsueb_publicl@homel . net> ; tag=184483 

Call -ID: cb0 3aOs0 9a2sdfgKlkj4 90 3 34 

Cseq: 127 INVITE 

Contact : <sip : icsueb_publicl@homel .net ;gr=urn:uuid: 2ad8950e-4 8a5-4a74-8d99- 

ad76cc7f c74>; +g . 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmt el "Content -Length: 



15. SIP re-INVITE request (intermediate IM CN subsystem entities to MGCF) 

Intermediate IM CN subsystem entity forwards the SIP re-INVITE request to MGCF according to normal IM 
CN subsystem procedure. 

16. SIP 200 (OK) response containing SDP-MGW (MGCF to intermediate IM CN subsystem entities) - see 
example in table A.6.2-16 

Table A.6.2-16: SIP 200 (OK) response (IVIGCF to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl . homel . net ;branch=z9hG4bK23436s . 1 , SIP/2. 0/UDP 

sccas. homel. net ;branch=z9hG4bK23d244 .1, SIP/2 .0/UDP 
Privacy: none 
From: 
To: 

Call-ID: 
Cseq: 

Contact : <sip :mgcf@homel .net>;+g. 3gpp . icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmt el" 
Content-Type : application/sdp 
Content-Length: (...) 
v=0 

o=- 2987933615 2987933615 IN IP6 f f f f : : adf : 333 : ccc : ddd 
s = - 

C=IN IP6 ffff : :adf :333 :CCC:ddd 
t=0 

m=audio 3456 RTP/AVP 97 96 
b=AS:2 5.4 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2 , 5, 7; maxframes=2 
a = r tpmap :96 telephone- event 



17. SIP 200 (OK) response 

Intermediate IM CN subsystem entities forward the SIP 200 (OK) response towards SCC AS. 

18. SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.6.2-18 

SCC AS sends a SIP INVITE request containing SDP-MGW as a SDP offer towards the private-URL 
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Table A.6.2-18: SIP INVITE request (SCC AS to intermediate IIUI CN subsystem entities) 



INVITE sip: 12345@ectas.homel.net SIP/2.0 

Via : SIP/2 . 0/UDP sccas .homel . net ; comp=sigcomp;branch=z9hG4bGnashds6 

Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted-Identity: <tel: +l-212-555-llll> 

Privacy: none 

From: <sip : icsueb_publicl®homel .net>; ; tag=1718 3 8 

To: <sip : 12345®ectas .homel .net> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Contact : <sip : icsueb_publicl@homel .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99- 

ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 
v=0 

o=- 2987933615 2987933615 IN IP6 f f f f : : adf : 333 : ccc : ddd 
s = - 

c = IN IP6 ffff : :adf :333 :ccc:ddd 
t=0 

m=audio 3456 RTP/AVP 97 96 
b=AS:2 5.4 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 
a = r tpmap :96 telephone- event 



19. SIP 100 (Trying) response 

The intermediate intermediate IM CN subsystem entnties respond to the SCC AS with a SIP 100 (Trying) 
response 

There is no ICS specific content in this response. 

20-21. SIP INVITE request / SIP 100 (Trying) response 

The intermediate IM CN subsystem entities forward the SIP INVITE request to private-URI, which will arrived 
at Transferor AS, and Transferor AS will add Replaces header field in the SIP INVITE request and send to UE C 
according to 3GPP TS 24.629 [19]. 

22. SIP 183 (Session Progress) provisional response (UE C to intermediate IM CN subsystem entities) - see 
example in table A.6.2-22 

UE C sends a SIP 183 (Session Progress) provisional response containing SDP-C as a SDP answer towards SCC 
AS via Transferor AS, according to normal IM CN subsystem procedure. 
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Table A.6.2-22: 183 (Session Progress) (UE C to intermediate IIUI CN subsystem entities) 



SIP/2.0 183 Session Progress 




Via: SIP/2. 0/UDP pcscfl.homel.net ;branch=z9hG4bK23G36a.O, SIP/2 


0/UDP 


scscf 1 .homel .net ;branch=z9hG4bK2 343 6s . 1 , SIP/2 . 0/UDP 




ectas.homel.net;branch=z9hG3bK3 82b2a.l, SIP/2. 0/UDP 




scscf 1 .homel .net ;branch=z9pG4bK3 92b2x. 1 , SIP/2 . 0/UDP 




sccas .homel .net; comp=sigcomp;branch=z9hG4bGnashds6 




Privacy: none 




From: 




To: 




Call-ID: 




Cseq: 




Contact : <sip :uec public lohomel .net ;gr=urn:uuid: e76 3c4acb-8-may- 


12bl-c678- 


12blc88c6fa2>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims 


icsi .mmtel" 


Content-Type : application/sdp 




Content-Length: (...) 




v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : adf : bbb : ccc : ddd 




s=- 

c = IN IP6 5555: : adf : bbb: ccc: ddd 




t = 




m=audio 3456 RTP/AVP 97 96 




b=AS:25.4 




a=rtpmap:97 AMR 




a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 




a=rtpmap:96 telephone -event 





23. SIP 183 (Session Progress) provisional response 

The intermediate IM CN subsystem entities forward the SIP 183 (Session Progress) provisional response to SCC 
AS via Transferor AS, according to normal IMS procedure. 

24-25. SIP ACK request 

The SCC AS acknowledges the SIP 200 (OK) response from MGCF with an ACK request containing SDP-C 
according to standard 3PCC procedure. 

26-27. SIP 200 (OK) response 

UE C answers the call and sends a SIP 200 (OK) response towards SCC AS according to normal IMS procedure. 

28. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities)- see example in table A.6.2-28 

The SCC AS response to the SIP INVITE request from ICS UE B with a SIP 200 (OK) response according to 
normal IM CN subsystem procedure. 

Table A.6.2 -28: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via : SIP/2 . 0/UDP sccas . homel . net ; branch=z9hG4bGnashds8 , SIP/2 . 0/UDP 

scscf 1. homel. net ;branch=z9pG4bK3 92b3o.l, SIP/2 .0/UDP 

pcscf2 .homel. net ;branch=z9hG4bK2 3G3 6b. 0, SIP/2 .0/UDP 
[3333 : :ccc :ddd: ccc :eee] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashdsB 
Privacy: none 
From: 
To: 

Call-ID: 
Cseq: 
Contact : <sip :uec_publicl@homel .net ;gr=urn:uuid: e763c4acb-8-may-12bl-c6 78- 

12blcBBc6fa2>; +g . 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel "Content - 

Type : application/sdp 
Content-Length: (...) 



Editor" s Note: The SDP in this SIP 200 (OK) response needs to be specified. 
29. SIP 200 (OK) response 
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The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to ICS UE B according to 
normal IM CN subystem procedure. 

30-31. SIP ACK request 

The ICS UE B acknowledges the SIP 200 (OK) from SCC AS with an ACK request according to normal IM CN 
subsystem procedure. 

32-33. SIP ACK request 

The SCC AS acknowledges the SIP 200 (OK) from UE C with an ACK request according to normal IM CN 
subsystem procedure. 

34. Session establishment 

A session is established between ICS UE B and UE C. 

35-38. SIP NOTIFY request / SIP 200 (OK) response 

The ICS UE B provides indication that the communication transfer is completed by sending a SIP NOTIFY 
request as specified in 3GPP TS 24.173 [9]. 

39. Session Release 

After communication transfer is completed the UE A releases the session with ICS UE B, and UE C releases the 
session with UE A according to the Replaces header field value. 

A. 6. 3 Communication Waiting 

A.6.3.1 Communication Waiting winen using Gm 

Figure A.6.3.1-1 illustrates the signalling flows for the Communication Waiting service when using Gm service control. 
This example shows an active session between the UE C and the ICS UE B with CS media bearer. The waiting session 
between UE A and the ICS UE B reuses CS media bearer. There can be other cases where the active session uses an IP 
media bearer and the waiting session uses a CS bearer and thus the CS bearer needs to be established. Alternatively the 
active session can use a CS bearer and T-ADS decision for the waiting call can result in deciding to use an IP media 
bearer. 
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Figure A.6.3.1-1 : Signalling flows for Communication Wait using Gm service control 

The details of the signalling flows are as follows: 

1 . Active session between UE C and ICS UE using CS bearers for media 

An active session exists between UE C and ICS UE. The ICS UE uses CS bearers for the audio media. 

2. SIP INVITE request (UE A to intermediate IM CN subsystem entities) - see example in table A.6.3.1-2. 

UE A originates a SIP INVITE request in order to establish a session with ICS UE, and thus the SIP INVITE 
request is forwarded towards the intermediate IM CN subsystem entities in the terminating network. 
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Table A.6.3.1-2: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE sip:user2_public2®home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route: <sip :pcscf 1 .homel .net ; lr>, <sip : scscf 1 . homel . net ; lr> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

P -Preferred- Identity : <sip :userl_publicl®homel .net> 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims . icsi .mmtel 

Accept -Contact : * ; +g. 3gpp . icsi -ref = "urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To: < sip :user2_public2@home2 .net > 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, 199 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-0 0a0c91e6bf 6>; 

+g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi . mmtel "> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept: application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 3400 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



3. SIP INVITE request (Intermediate IM CN subsystem entities to TAS with CW) 

As a result of filter criteria evaulation at the terminating S-CSCF, the SIP INVITE request is forwarded to the 
TAS with CW. 

4. CW detection at the TAS with CW (Network determined user busy) 

The AS detects the CW condition and inserts a CW indication into the SIP INVITE request as described in 
3GPPTS 24.615 [18]. 

5. SIP INVITE request (TAS with CW to Intermediate IM CN subsystem entities) - see example in 
Table A.6.3.1-5 
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Table A.6.3.1-5: SIP INVITE request (TAS WITH CW to intermediate IM CN subsystem entities) 



INVITE sip:user2_public2®home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK332b33 . 1 , SIP/2. 0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bK8 71yl2 .1, SIP/2. 0/UDP 

scscf 1. homel.net ;branch=z 9hG4bK3 3 2b2 3 .1, SIP/2 .0/UDP 

pcscfl. homel.net ;branch=z9hG4bK431h2 3 .1, SIP/2 .0/UDP 

[5555 : :aaa:bbb: ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 70 
Route : <sip : cwas2 . home2 . net ; lr> , <sip : cb03aOs09a2sdf glkj 490333@scscf 2 . home2 . net ; lr> ; orig- 

dialog-id="0: 73 935718_92 £45110- 712 78Gjd2463 953 02d-zKE" 
Record- Route :<sip:scscf2 .home2 .net;lr>, <sip:scscfl .homel .net ; lr>, <sip : pcscfl .homel .net ; lr> 
P-Access-Network-Info : 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-212-555-llll> 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 
P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims . icsi .mmtel 

Accept -Contact : * ; +g. 3gpp . icsi -ref = "urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 
Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=6 8 73 64 
To: <sip :user2_public2@home2 .net > 
Call -ID: Cb03a0s09a2sdf glkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, 199 
Contact : <sip : userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6>; 

+g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi . mmtel "> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept: application/sdp, application/3gpp-ims+xml 
Content - Type : mul t ipart /mixed ; boundary= " boundaryl " 
Content-Length: (...) 

--boundaryl 

Content-Type: application/sdp 

v=0 
o=- 
s = - 
c= 

t= 

m= 



--boundaryl 

Content-Type : application/3gpp-ims+xml 
Content -Disposition: 3gpp- alternative -service 

<3gpp-ims version="l"> 
< alternative- service > 
<type/> 
<reason/> 
<action> 

<call-waiting-indication/> 
</action> 
< /alternative- service > 
</3gpp-ims> 
--boundaryl-- 
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6. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

As a result of further iFC evaluation, the SIP INVITE request is routed towards the SCC AS. 

7. T-ADS 

The SCC AS performs T-ADS and selects Gm service control to be used with CS media bearers. 
8-9. SIP INVITE request (SCC AS to ICS UE B via Intermediate IM CN subsystem entities) 

The SIP INVITE request is routed towards the ICS UE B. 

10-1 1. SIP 180 (Ringing) response (ICS UE B to Intermediate IM CN subsystem entities) 

ICS UE B responds with a SIP 180 (Ringing) response with an Alert-Info header field set to 
"urn:alert:service:call-waiting" according to draft-alexeitsev-bliss-alert-info-urns [38], which is routed towards 
the SCC AS through the intermediate IM CN subsystem entities. 

12. Hold/resume call between UE C and ICS UE B 

[out of scope: user B uses the Call Hold service as specified in subclause 12.2.4 or releases a call] 

13-14. SIP 180 (Ringing) response (SCC AS to TAS WITH CW via IM CN subsystem entities) 

The SCC AS sends the SIP 180 (Ringing) response with a Alert-Info header field set to "um:alert:service:call- 
waiting" according to draft-alexeitsev-bliss-alert-info-urns [38], towards the TAS WITH CW. 

15-16. SIP 180 (Ringing) response (TAS WITH CW to UE A via IM CN subsystem entities) 

The SIP 180 (Ringing) response is forwarded through the intermediate IM CN subsystem entities and the 
originating IM CN subsystem towards UE A. 

A.6.3.2 Communication Waiting via tine MSC Server eniianced for ICS 

Figure A.6.3.2-1 illustrates the signalling flows for the Communication Waiting service via the MSC Server enhanced 
for ICS. This example shows an active session between a UE and the CS UE with CS media bearer. The waiting session 
between a UE C and the ICS UE reuses CS media bearer. 
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1 7a. the MSC Server enhanced for iCS inserts a Aiert-info header 
with a CW um into the 180 Ringing response 



t 17b. 180 Ringing Aiert-info: urn:aiert:service:caii-waiting- 

18. 180 Ringing 

Aiert-info: 

urn:aiert:service: 

caii-waiting 

19. 180 Ringing 
Aiert-info: 

urn:aiert:service: 
caii-waiting 

20. 180 Ringing 

Aiert-info: urn:aiert:service: 

caii-waiting 

21a. 180 Ringing 

« Aiert-info: urn:aiert:service: 

caii-waiting 
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the caiiing user 



16d. Possibiiity for User B to 

react: reiease session, invoke 
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Figure A.6.3.2-1 : Communication Waiting via the IVISC Server enhanced for ICS 

The details of the signalHng flows are as follows: 

la. Active session between a UE and CS UE using CS bearers for media 

An active session exists between a UE and CS UE. The CS UE uses CS bearers for the audio media. 

lb. SIP INVITE request (originating IM CN subsystem entities to intermediate IM CN subsystem entities) ■ 
see example in table A.6.3.2-lb. 

A SIP INVITE request is forwarded towards the intermediate IM CN subsystem entities in the terminating 
network in order to establish a session with the CS UE. 



Table A.6.3.2-1 b: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE sip:user2_public2®home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 
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Max- Forwards : 70 

Route: <sip ipcscf 1 .homel .net ; lr>, <sip : scscf 1 .homel .net ; lr> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-212-555-llll> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims . icsi .mmtel 

Accept -Contact : * ; +g. 3gpp . icsi -ref = "urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To: < sip :user2_public2@home2 .net > 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, 199 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5-0 0a0c91e6bf 6>; 

+g. 3gpp . icsi-ref ="urn%3Aurn-7%3gpp-service . ims . icsi .mmtel" > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept: application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 34 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 



4. SIP INVITE request (Intermediate IM CN subsystem entities to TAS with CW) 

As a result of filter criteria evaulation at the terminating S-CSCF, the SIP INVITE request is forwarded to the 
TAS with CW. 

6. CW detection at the TAS with CW (Network determined user busy) 

The AS detects the CW condition and inserts a CW indication into the SIP INVITE request as described in 
3GPPTS 24.615 [18]. 

7. SIP INVITE request (TAS with CW to Intermediate IM CN subsystem entities) - see example in 
table A.6.3.1-7 

Table A.6.3.1-7: SIP INVITE request (TAS with CW to intermediate IM CN subsystem entities) 



INVITE sip:user2_public2@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK332b33 . 1 , SIP/2. 0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscf 1. homel. net ;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

pcscfl. homel. net ;branch=z9hG4bK431h23 .1, SIP/2 . 0/UDP 

[5555 : : aaa : bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 

Route : <sip : cwas2 .home2 .net ; lr>, <sip : Cb03a0s09a2sdfglkj490333@scscf 2 .home2 .net; lr>;orig- 
dialog-id="O:73935718_92645110- 712786 jd2463953 02d-zKE" 
Record- Route : <sip:scscf2 .home2 .net;lr>, <sip:scscfl .homel .net ; lr>, <sip : pcscfl .homel .net ; lr> 
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P-Access-Network-Info : 

P-Asserted- Identity : 

P-Charging-Vector : 

P-Asserted-Service : 

Accept-Contact : 

Privacy: 

From: <sip :userl_publicl@homel .net>; tag=6 8 73 64 

To: 

Call-ID: 

Cseq: 

Supported: 

Contact : 

Allow: 

Accept : 

Content - Type : mul t ipart /mixed ; boundary= " boundaryl " 

Content-Length: (...) 

--boundaryl 

Content-Type: application/sdp 



v=0 
o=- 
s = - 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
a= 
a= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



--boundaryl 

Content -Type : application/3gpp-ims+xml; sv="2" 
Content -Disposition: 3gpp- alternative -service 

<3gpp-ims version="2"> 

Content-Type : application/3gpp-ims+xml 

Content -Disposition: 3gpp- alternative -service 

<3gpp-ims version="l"> 
< alternative- service > 
<type/> 
<reason/> 
<action> 

<call-waiting-indication/> 
</action> 
< /alternative- service > 
</3gpp-ims> 
- -boundaryl- - 



10. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

As a result of further iFC evaluation, the SIP INVITE request is routed towards the SCC AS. 

12-13. SIP INVITE request (SCC AS to the MSC Server enhanced for ICS via Intermediate IM CN 
subsystem entities) 
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The sec AS selects the MSC Server enhanced for ICS.The SIP INVITE request is routed towards the CS UE. 
16. SIP 180 (Ringing) response (CS UE and MSC Server enhanced for ICS) 

MSC Server enhanced for ICS and the CS UE signal according to 3GPP TS 24.083 [26]. 

17-22. SIP 180 (Ringing) response (CS UE to Intermediate IM CN subsystem entities) 

ICS UE B responds with a SIP 180 (Ringing) response with a Alert-Info header field set to 
"urn:alert:service:call-waiting" according to draft-alexeitsev-bliss-alert-info-urns [38], which is routed towards 
the sec AS through the intermediate IM CN subsystem entities. 
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Annex B (normative): 

Media feature tags defined within the current document 

B.1 General 

This subclause describes the media feature tag definitions that are applicable for the 3GPP IM CN Subsystem for the 
realisation of ICS. 

B.2 Definition of media feature tag g.Sgpp.ics 

Media feature-tag name: g.3gpp.ics 

ASN.l Identifier; 1.3.6.1.8.2.x 

Editors note: The ASN. 1 Identifier will need to be updated once the lANA registration is completed. 

Summary of the media feature indicated by this tag: This feature-tag when used in a SIP REGISTER request indicates 
that the function is ICS capability and may operate in ICS mode. This feature-tag when used is a none SIP REGISTER 
method indicates that the function wants to invoke ICS functionality. 

Values appropriate for use with this feature-tag: principal; server. 

principal When used in a SIP REGISTER request indicates that the function that is ICS capable is a mobile phone. 
When used in another SIP method indicates that the function wants to invoke ICS functionaUty. 

server Indicates that the function that is ICS capable is a network node. 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is most useful in a communications application, for describing the capabilities of a device, 
such as a phone or PDA. 

Examples of typical use: Indicating that a mobile phone (principal) can support or wants to use ICS or that a network 
node (server) wants to invoke ICS functionality 

Related standards or documents: 3GPP TS 24.292 [11]: "3GPP Technical Specification: IP Multimedia (IM) Core 
Network (CN) subsystem Centralized Services (ICS); Stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 12.1 of 
IETF RFC 3840 [34]. 

B.3 Definition of media feature tag g.Sgpp.accesstype 

Media feature -tag name: g.3gpp.accesstype 

ASN.l Identifier. 

Editors note: The ASN. 1 Identifier will need to be updated once the lANA registration is completed. 

Summary of the media feature indicated by this tag: This feature-tag when used in a SIP REGISTER request indicates 
access network technology used by the device and the particular registration flow that the device is using to register 
over. 

Values appropriate for use with this feature-tag: string with an equality relationship 

Examples 

"wlanl" : the UE is using WLAN access technology. 
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"cellular2": the UE is using cellular access technology. 

"docsis4": the UE is using DOCSIS access technology. 

"dsl3": the UE is using DSL access technology. 

"ethernetS": the UE is using Ethernet access technology. 

This list is not exhaustive. 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is most useful in a communications application, for describing the capabilities of a device, 
such as a phone or PDA. 

Examples of typical use: Indicating the access technology that the device is using 

Related standards or documents: 3GPP TS 24.292 [11]: "3GPP Technical Specification: IP Multimedia (IM) Core 
Network (CN) subsystem Centralized Services (ICS); Stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 12.1 of 
IETF RFC 3840 [34]. 
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